Step # 6: Now make the Get Profile Image call to get the Image content of the profile photo.
Make an HTTP call to get the profile image.
# Please use the highlighted values for URI and Headers.
{
"inputs": {
"method": "GET",
"uri": "https://graph.microsoft.com/v1.0/users/@{triggerBody()['text']}/photo/$value",
"headers": {
"responseType": "blob",
"Content-Type": "blob",
"Authorization": "@{body('ParseJSONforToken')?['token_type']} @{body('ParseJSONforToken')?['access_token']}"
}
},
"metadata": {
"operationMetadataId": "775579d0-6aa9-4326-a1f9-0ad37217c304"
}
}
Step # 7: Finally add compose section to get the image content from the above action.
Conclusion
As shown in the above technique you can get the user profile images on the tenant. The Azure AD app plays an important part to make an MS Graph API call. The same API call can be made using the PUT and you should be able to apply a badge or anything else to the user profile picture.
Step # 1 Create an Azure AD app with the MS Graph “DeviceManagementManagedDevices.Read.All” permission.
MS Graph “DeviceManagementManagedDevices.Read.All” permission.
Please note the Application ID, Secret, and Tenant ID. You will need these three pieces of information in the PowerShell Script.
Step # 2 Using PowerShell run the following script.
# Init Variables
$outputPath = "C:\Hold"
$outputCSVPath = "C:\Hold\EAWFAreport.zip" #might need changed
$ApplicationID = "TOBE CHANGED"
$TenantID = "TOBE CHANGED"
$AccessSecret = "TOBE CHANGED"
#Create an hash table with the required value to connect to Microsoft graph
$Body = @{
grant_type = "client_credentials"
scope = "https://graph.microsoft.com/.default"
client_id = $ApplicationID
client_secret = $AccessSecret
}
#Connect to Microsoft Graph REST web service
$ConnectGraph = Invoke-RestMethod -Uri https://login.microsoftonline.com/$TenantID/oauth2/v2.0/token -Method POST -Body $Body
#Endpoint Analytics Graph API
$GraphGroupUrl = "https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs"
# define request body as PS Object
$requestBody = @{
reportName = "Devices"
select = @(
"DeviceId"
"DeviceName"
"SerialNumber"
"ManagedBy"
"Manufacturer"
"Model"
"GraphDeviceIsManaged"
)
}
# Convert to PS Object to JSON object
$requestJSONBody = ConvertTo-Json $requestBody
#define header, use the token from the above rest call to AAD.
# in post method define the body is of type JSON using content-type property.
$headers = @{
'Authorization' = $(“{0} {1}” -f $ConnectGraph.token_type,$ConnectGraph.access_token)
'Accept' = 'application/json;'
'Content-Type' = "application/json"
}
#This API call will start a process in the background to #download the file.
$webResponse = Invoke-RestMethod $GraphGroupUrl -Method 'POST' -Headers $headers -Body $requestJSONBody -verbose
#If the call is a success, proceed to get the CSV file.
if ( -not ( $null -eq $webResponse ) )
{
#Check status of export (GET) until status = complete
do
{
#format the URL to make a next call to get the file location.
$url2GetCSV = $("https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs('{0}')" -f $webResponse.id)
"Calling $url2GetCSV"
$responseforCSV = Invoke-RestMethod $url2GetCSV -Method 'GET' -Headers $headers -verbose
if (( -not ( $null -eq $responseforCSV ) ) -and ( $responseforCSV.status -eq "completed"))
{
#download CSV from "URL=" to OutputCSVPath
#### It means the completed status is true, now get the file.
Invoke-WebRequest -Uri $responseforCSV.url -OutFile $outputCSVPath
# Un Zip the file.
Expand-Archive -LiteralPath $outputCSVPath -DestinationPath $outputPath
}
{
Write-Host "Still in progress..."
}
Start-Sleep -Seconds 10 # Delay for 10 seconds.
} While (( -not ( $null -eq $responseforCSV ) ) -and ( $responseforCSV.status -eq "inprogress"))
}
After this PowerShell script call, you should see the Zip and CSV files in the C:\Hold Folder.
Conclusion
The above steps will help you to get the InTune reports data file. The API still in the beta if anything changes I will update this post.
My customer has migrated the classic sites to SharePoint Online. Some sites’ home pages are with the list view web part, these pages make multiple query calls to Search API every 60 seconds.
This will make Search API throttle the query and it may have a bad user experience if many users frequently visit the same page multiple times. Read this article on the details of throttling.
Step by Step to diagnose the issue
For an issue like throttling, to diagnose you will need the Browser’s Developer Tools, you can get more information here about the developer tool for the Edge browser.
Go to the SharePoint page with List View WebPart. Open the Network tab and watch for the outbound traffic. You will notice every 60 seconds the ListView WebPart will try to refresh.
This happens because the following are the settings for the list view web part.
“Automatic Refreshing interval (seconds)”
Increase the auto-refresh interval and turn it on to show the manual refresh button.
Conclusion
This may be a simple thing and can cause issues only if the page is popular and many users are visiting at the same time. If the user leaves the page active for a long time the auto-refresh will make the call in the interval and the user may not even need the refresh.
The better fix for such a page, increase the interval and provide the manual refresh button so as per the user’s need they can refresh. This will also reduce unnecessary calls to the Search API.
The following command can be used to set the Versionins and Major / Minor version numbers.
# In this command the minor version in the UI (as aboove) is the draft version.
Set-PnPList -Identity "Documents" -EnableVersioning $true -MajorVersions 25 -EnableMinorVersions $true -MinorVersions 10
#
There are two files to automate the process of turning on versioning. The input file is site2process.CSV. The input file is with list of Site Collection URLs to process.
The following are the customer concerns with the SharePoint sites on Microsoft 365 cloud regarding audit reports.
SPO site collection admins do not receive the same GUI presentation for site audit reports that were available on the SharePoint on-premises.
Currently, the reports are available only in the CSV files.
Currently, O365Tenant admins must run the report to get the CSV files
As per the customer, in the SharePoint on-premises SCA could set the following audit options and pull it from the Site Settings. The same is not possible in SPO.
Opening or downloading documents, viewing items in lists, viewing item properties
Editing items, Checking out or checking in items, Moving or copying items to another location on the site, Deleting or restoring items
Editing content types or columns, Searching site content, Editing users and permissions
SharePoint on-premises these options events were available to audit.
Step by Step Solution
The SharePoint online workload in Microsoft 365 tracks audit logs data at the tenant level. The tenant administrator can get these data (in CSV format) from the compliance center portal, which is a manual process for the admin.
To automate the process Office 365 Management API can be used to get these audit data. There are two types of Office 365 Management API?
Office 365 Service Communications API, which can do the following:
Get Services: Get the list of subscribed services.
Get Current Status: Get a real-time view of current and ongoing service incidents.
Get Historical Status: Get a historical view of service incidents.
Get Messages: Find Incident and Message Center communications.
Office 365 Management Activity API, which can do the following.
Use the Office 365 Management Activity API to retrieve information about the user, admin, system, and policy actions and events from Office 365 and Azure AD activity logs.
Audit and activity logs to create solutions that provide monitoring, analysis, and data visualization.
The Office 365 Management Activity API allows for pulling of audit logs for the following workloads.
Audit.AzureActiveDirectory
Audit.Exchange
Audit.SharePoint
Audit.General (includes all other workloads not included in the previous content types)
DLP.All (DLP events only for all workloads)
Step # 1 In Compliance Center turn on auditing
Go to https://compliance.microsoft.com and sign in.
In the left navigation pane of the Microsoft 365 compliance center, click Audit.
If auditing is not turned on for your organization, a banner is displayed prompting you to start recording user and admin activity.
Click the Start recording user and admin activity banner.
It may take up to 60 minutes for the change to take effect.
Compliance Center to turn on auditing
Step # 2 Register an Azure AD App
To register the Azure AD application you can follow this step.
Add and grant consent to the following Application permissions. – Office 365 Management API 1. ActivityFeed.Read 2. ActivityFeed.ReadDlp 3. ServiceHealth.Read
Step # 3 Start a subscription for a workload(s)
Prior to making this call you will need to get the Access Token by using the Azure AD app. The following call will add Audit.SharePoint, you can add more workloads.
*** REQUEST TO BE MADE ***
POST {root}/subscriptions/start?contentType=Audit.SharePoint&PublisherIdentifier={TenantGUID}
Content-Type: application/json; utf-8
Authorization: Bearer eyJ0e...Qa6wg
RESPONSE
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
{
"contentType": "Audit.SharePoint",
"status": "enabled",
}
Step # 4 Activity API operations
After one time subscription, you can make a call to the feed API to get audit information. The subscription can be stopped as well.
*** MAKE a Call to get the list of Audit reports ***
*** StartTime and End Time must not exceed 24 hours ***
*** The times must be in the form of yyyy-MM-ddTHH:mm:ss.fffZ ***
*** PowerShell $startTimeDt.ToString("yyyy-MM-ddTHH:mm:ss.fffZ")" ***
REQUEST
GET https://manage.office.com/api/v1.0/{{TenantID}}/activity/feed/subscriptions/content?
startTime={{startTime}}&
endTime={{endTime}}&
contentType={{contentType}}&
PublisherIdentifier={{TenantID}}
RESPONSE
[
{
"contentUri": "https://manage.office.com/api/v1.0/b07282ed-2513-42ff-8322-de55ebce98f1/activity/feed/audit/20220404172343761148151$20220405052516832093374$audit_sharepoint$Audit_SharePoint$na0034",
"contentId": "20220404172343761148151$20220405052516832093374$audit_sharepoint$Audit_SharePoint$na0034",
"contentType": "Audit.SharePoint",
"contentCreated": "2022-04-05T05:25:16.832Z",
"contentExpiration": "2022-04-11T17:23:43.761Z"
},
{
.... removed for brevity
]
Step # 5 Using the above response for each “contentUri” make another get call to get the JSON response
As you can see from the response there are multiple data in the JSON response. These data can be different based on what content type is subscribed. Here is the schema for all response values.
After the above steps you should be able to see the audit data. But these are all manual steps to get the content. To automate these you will need to use the Azure resources such as Azure Storage, Azure Functions, and Azure Cosmos DB. The following is the logical architecture that depicts those Azure resources.
Logical Architecture for automating to get the audit data
The Power BI Premium license is required for the dashboard.
List of required Azure resources for the automating the audit log solution
To create the above resources in your Azure demo tenant you can use this ARM template.
The Queue Events Azure Function Code is located here.
The Store Events Azure Function Code is located here.
Once the data is gathered in the Azure Cosmos DB, the Power BI can generate a report similar to the following. The report shown is a basic example but once the data is collected to the Azure Cosmos DB you can create more such reports to meet your audit need.
The report can answer the following questions:
Who did an operation to the File, List, or Library?
When the operation was performed?
What operation was performed?
What sites are used?
The Audit report from the audit data gathered in the Azure Cosmos DB.
The above solution is a proof of concept (POC) for SharePoint or OneDrive data. There are other workloads audit data that can collect such as Exchange, DLP, Azure AD, etc.
This is the final part of the three-part blog post.
Part1 and Part2 posts were focused on the basic settings for the Classic UI mode pipeline setup. In this post, I will explain more advanced, modular, and factory pattern ways of the CI/CD Azure DevOps pipelines.
My customer has Azure DevOps Server (ADOS) and pool agent as Windows OS for the default pool.
As defined in Part1, the prerequisite still applies to this approach. Additionally, you will need to have some basic familiarity with the YAML language. You will need the Git installed on your local machine. This approach uses the Microsoft Power Platform CLI. The Pac CLI performs better than Power Platform Build Tools defined in Part2.
Step by Step solution
Step # 1 Create an organization and project in your Azure DevOps.
Create a new project in the Azure DevOps organization
Copy the above two folders to the cloned local repo.
Step # 5 Using the following Git commands push the changed code to the Azure DevOps repo.
# this will check the status as untacked changes
git status
# this command will add the untracked changes to the local as tracked
git add .
# this command will commit to the local repository
git commit -m "Added .azdops and pwsh folders"
# this command will push the local commited changes to the remote repoository
git push
The four commands to push the two folders and files to the Azure DevOps repo.
The final results to the Azure DevOps repository should look similar to the following. The .azdops and pwsh folders should be the top folder in your repository.
The Azure DevOps repository final result.
Step # 6 Create Azure Pipelines variable groups ‘Credentials’, ‘Dev’, ‘Test’, and ‘Prod’.
In the ADO project, click on the Library and Add the four variable groups. Now create variables in these variable groups. These variable groups are used in the YAML code. Please keep the name as defined below for variable groups and variables.
Add four variable groups.
#
# Variable Group Crendential will have the following three variables.
#
ClientId = {Get the value from the Part1 blog post Step # 3 }
ClientSecret = {Get the value from the Part1 blog post Step # 3 }
TenantId = {Get the value from the Part1 blog post Step # 3 }
#
# Variable Group 'Dev', 'Test', 'Prod' will have the following variable.
# The Url value will be different for all three.
#
Url = {Get the value from the Part1 blog post Step # 2 }
Note: The above values will be used in the pipeline.
Under pipelines -> environments, define test and prod environments. The environments can be used for adding any approval requirements.
Create test and prod environments
For the prod environment, (optional) add the approval settings. Assign one or more approvers.
Assign approver to the prod environment.
Step # 9 Create a Pipeline using the existing file .azdops\pipelines\export-commit.yml
(Note: a longer step)
Click Create Pipeline button under the Pipelines
Select Azure Repos Git
Select the Repository for the project.
Select the ‘Existing Azure Pipelines YAML file.
Select ‘export-commit.yml’ file
Finally, review the code and click the arrow to save the pipeline. DO NOT RUN at this time.
Now rename the newly created pipeline by clicking 1, 2, and 3 as shown above.
Rename it to “Export and Commit by Solution Name Variable”
First, add the variable ‘SolutionName’ before running the pipeline.
Note: You will get the following error when you run the pipeline. YOU NEED TO set Contribute Allow for the build agent.
“remote: TF401027: You need the Git ‘GenericContribute’ permission to perform this action.”
An error when you run the pipeline the first time.
Change the Contribute settings to Allow for the Build Service agent.
Upon successful pipeline run, you should see your Solution under the solution folder as shown above.
Step # 8 Setup multi-stage build and deploy pipeline for .azdops\pipelines\build-deploy.yml
Consider the file .azdops\pipelines\build-deploy.yml as the template for your Power Platform Solution. From the above example for ‘Spark2022’ solution name I created the copy of the template to a new file named ‘Spark2022-build-deploy.yml’.
Make a copy of ‘build-deploy.yml’ template file for your solution. Replace the Demo2022 text from the yml file.
Step # 10 Create a Pipeline using the existing file .azdops\pipelines\{YOUR SOLUTION NAME}-build-deploy.yml
Note: You will repeat most of the solution steps from Step # 7 above. Please refer above for the screenshots.
Click on Pipeline, then click the “New pipeline” button.
Select Azure Repos Git
Select your specific repository
Select the “Existing Azure Pipelines YAML file”
Select the /.azdops/pipelines/{YOURSOLUTIONNAME-build-deploy.yml file. (You created in the step # 8)
DO NOT Run yet, click on the down arrow next to the Run blue button. Select Save.
Now click on Pipelines from the left menu. Click on the “All” tab.
Click on the newly created pipeline to rename, see below.
Rename the new pipeline.
Rename to something like “{YourSolutionName} Build and Deploy”. So for the above example, it would be “Spark2022 Build and Deploy”
Rename to “{YourSolutionName} Build and Deploy”
Step # 11 Create config.test.json and config.prod.json files (if not present) under the solution folder.
The two config files for the test and prod are under your Solution Folders directory.
Two config files for test and prod with empty JSON for now.
The save of these files will trigger the build if not, run the pipeline, you will see the multi-stage for Build, Test, and Prod
NOTE: In this pipeline, you do not need to set any variable before running it.
The build and deploy three stages.
Step # 12 Regarding the config.test.json and config.prod.json files.
This is an optional step. You may have environment variables for the connection references, site URL, list guide, etc. These variables are different in each environment. The values for deployment can be configured in the config.ENV.json file.
#
# Use the *unmanged* solution to extract dev config setting.
#
pac solution create-settings --solution-zip Spark2022.zip --settings-file config.dev.json
Dev config Settings using Pac CLI.
CITIZEN DEVELOPER SCENARIO
All above steps 1 to 12 are for the Build Administrator or Technical lead of the project.
For the Citizen developer’s role, the steps are simple and as follows.
Gather the requirements or feedback or bugs for the application.
Create a Power Platform Solution in the Dev Environment e.g. LaptopInventory
Develop a PowerApps App
Develop a PowerAutomate Flow
Creates a List and any other components required for the solution.
Test the application and flow
Run Export and Commit Pipeline (export-commit.yml) for the LaptopInventory solution.
Note: you need to add a SolutionName=LaptopInventory variable before running the pipeline
This action will create a new directory ‘LaptopInventory’ in the repository
Create config.test.json and config.prod.json files with an empty record as {}
Note: This is a one-time activity. It can be repetitive if you are adding any config variables for various environments.
Create a Build and Deploy Pipeline for the solution ‘LaptopInventory’ (See Step#8 and Step#9)
Note: This is a one-time activity
Make a copy of build-deploy.yml to LaptopInventory.yml in the ‘.azdops\piplelines‘ folder
Change the text from ‘Demo2022’ to the ‘LaptopInventory’
Create a Pipeline using the new YML file
Run the pipeline if it is not running already. (This action will make the Solution available in the Test Environments)
Ask Testers to test and provide feedback.
Repeat the above steps from here as needed for the ALM cycle.
The below flow chart gives an overview of the process. The developers run the “Export & Commit” by the SolutionName. This action “1” exports the Solution and Commits to the Source Control Managemen (SCM). The checking in the file(s) for the solution auto triggers the “Build & Release” pipeline which eventually put the managed solution in the TEST or PROD environments.
Depending on the feedback from the testers the above process is repeated by the developer.
My customer needs a way to help the developers to create CI/CD pipeline build for the developers. The customer has the Azure DevOps Server (ADOS). They need guidelines for the DevOps process for SPFx projects.
The requirement is to utilize the existing shared build agents which were Windows VMs. Additionally, the deployment should be in the site collection app catalog not in the app catalog.
The sample on the web provided by Andrew Connel was a very good start. I modified it to meet the above requirements. I hope this may be helpful to you.
Prerequisites
Azure DevOps (ADO) Server if not you can utilize the online ADO. (Follow this article to get a free five-user Basic Plan Azure Subscription.)
GitHub Repo
Step By Step Solution
Step # 1: Create a Jobs folder in your source repo.
The following three URLs will be handy, the first one is to register a new app, the second is to set the permissions for the app and the third one is to list apps you or others have previously created.
https:// [Your SharePoint Site URL]/_layouts/15/AppRegNew.aspx
https:// [Your SharePoint Site URL]/_layouts/15/AppInv.aspx
https:// [Your SharePoint Site URL]/_layouts/15/AppPrincipals.aspx
Step # 5: Finally you need to create the following two variables in the pipelines.
ClientID
ClientSecret
Conclusion
The above steps were to provide the CI/CD pipelines to deploy the SPFX packages to the site collection app catalog.
To know more about SPFx. Please use the following links.
If you have large Power Automate flow and you have used a lot of variables and have looping, I bet your flow performance is not good. If that is the problem, please keep reading you may benefit from this post.
Few simple facts:
The Power Automate looping can run in concurrency. In other words, the actions like apply-to-each or do-while can run concurrently in parallel.
If in the loops the variables is modified using append-to-variable action, internally Power Automate puts the LOCKS on the variables. This is by design so any other area of the concurrent code does not modify the value at the same time.
This lock and unlock of variables takes time and your flow suffers from the performance.
DON’T use variable modification in the loop.
What is the solution?
The answer is to use the Compose. You may ask, but wait? the Compose action is by design to put the constant values.
Yes, that is correct the Compose action is for the constant. But there is a technique to get the values out from the loop using Compose.
Step By Step Solution
To demonstrate the issue and solution I will make use of the Compose and Variable actions in the parallel flow. I will create an array of integers using the range method.
Step # 1 Create the Manually trigger flow
Step # 2 Add a Compose Action with expression as follows. Rename it to ‘const array’
range(0,100)
Step # 3 Add an Initialize Variable with Name as ‘array’ and type as an ‘Array’ and add the same above expression for Value. Rename action to ‘var array’
After step # 3, you will have something like this.
Step # 4 Add Apply to each action and rename to “Apply to each const array”
Step # 5: Inside this apply-to-each add a Compose action with expression for “Current Item”
Step # 6: An important step, add a TEMP Compose 2 action and expression as the output of the above Compose.
Step # 7: Using the peek code take the expression value. It should be like the following. You need only bold values from it.
{
"inputs": "@outputs('Compose')"
}
Step # 7: Add new Compose 3 action “Outside” of the apply-to-each loop. In the expression using the above expression. Rename it as ‘log cont array’
Step #8: You do not need the Compose 2 action we added in Step 6. So delete it now.
After step 7, you should have the flow as shown above.
Step # 9: You now will add the parallel branch next to the previous apply-to-each action. Add Initialize variable steps with Name as ‘results’, Type as an ‘Array’, and value as two square brackets [].
Step # 10: Add second apply-to-each on the ‘array’ variable rename it as ‘Apply to each var array’
Step # 11: Add ‘Append to array variable’, pick the results variable and Value as the ‘Current item’ of the second apply to each action.
Step # 12: Add the final Compose to display the results variable. Name it as ‘log var results’
After step 12, the flow should be like the above.
Step # 13 Finally you want to turn on concurrency for both the flows. Click on the ‘Settings’ for both apply-to-each actions. Turn on the concurrency and set parallelism to 50.
setting parallelism
Run the flow now and see the results. I get the following results.
The Compose inside the loop finishes in 2 seconds whereas the variables in the loop take 12 seconds.
using Compose inside the loop vs variables.
Nott: You can download and import the above sample flow in your environment. The export zip file is located here.
Conclusion
Obviously, the compose action gives better satisfactory performance over the variables for using inside the loop. Additionally, concurrency with parallelism provides better performing flow.
I have just re-wrote the same technique Pieter and John Lui have presented or blogged about this method.
As you know the Power Virtual Agent (PVA) is a low-code and no-code solution. It is very easy to create a Bot quickly. Now, if you want this bot on the SharePoint page. There are a few options and their pros & cons.
In this article, I am going to list out all options. I will share the pros and cons of each option and share code where needed. This will help you guide your journey for a similar requirement.
Prerequisites
There are a few prerequisites, based on which option you pick you will need to get one or more of the following resources.
Power Platform Environment – Required for all options
SharePoint Online tenant – Required for all options
SharePoint Framework Development (SPFx) Environment Setup – Required for Options # 3
Below are the three options:
Option # 1: Put embedded code from the bot on an IFRAME on the SharePoint page.
Pros:
Easy and quick
Easy to get embed code from the PVA Bot Channels.
Easy step to add the IFRAME on the SharePoint page
Cons:
The embed code has the code and the token is exposed as public for the content owner. If this code with url is leaked anyone from outside of the organization network can access the Bot. If this Bot is meant to be internal to organization then this option will not work.
Option # 2: Use DirectLine (DL) Secret and get DL Token from Azure Web Site URL for IFRAME on the SharePoint page.
Basically, in this approach, the IFRAME will be still used on the SharePoint page. But the URL for the IFRAME will be from the internally controlled Web Site URL which will be blocked from public access using IP restrictions. The internal website will be configured with the Direct Line Secret. The website will get the Direct Line Token for doing secured communication with the Bot.
Pros:
The bot will NOT be accessed by the public. It will be restricted by the website for the internal IP range only. Even if the URL is leaked it will be blocked by the IP Restriction on the Azure Front Door.
It used the Bot’s direct line Token as a protected communication mechanism.
There will be code on the Azure Web App to create and maintain
Option # 3: Create an SPFx Application Customizer to put on the SharePoint page.
Pros:
The bot will not be exposed to the public. The Direct Line Secret will be buried in the SPFx code & can not be seen
Cons:
There is SPFx web part development and in future for maintenance (if needed).
Step By Step Solution:
Option # 1:
The following two steps will get your Bot on the SharePoint page quickly.
This is an easy solution. All you need to do is to get the embed code from the Bot. Follow here.
Once you get the code you add this to your SharePoint page. Follow here.
Option # 2:
This option will use Azure Web App and Azure Front Door. The Azure Front Door will allow to restriction of IP within the organization.
The Azure Web App is the ASP.NET Core solution. There are two components in the website, one is to UI and the other is API. The UI part is to show the Web Chat and API is to get the Direct Line Token from the Secret. The Direct Line Secret is stored in the configuration of the website or can be secured using a key vault.
TODO: Code to follow.
Option # 3:
TODO: Code to follow.
Conclusion
Based on the above article’s options and their pros and cons you will be able to decide what is right for your need. Option #1 is very easy and quick to Option # 3 to get modern ways to block the access.
Pankaj Surti's Blog 
