Arin's Tech Musings

For those that have been working with conversational interfaces namely bots, both developers and business users, have at some point come across the term transcript. So what is a " bot transcript file "? According to docs.microsoft.com, "A bot transcript file is a specialized JSON file that preserves the interactions between a user and your bot. A transcript file preserves not only the contents of a message, but also interaction details such as the user id, channel id, channel type, channel capabilities, time of the interaction, etc. All of this information can then be used to help find and resolve issues when testing or debugging your bot." If we look closely at this definition, we can see that a transcript is much more than just contents of messages exchanged between user and bot. It contains a lot more information in it's raw form. Thereby, it is quite evident that a transcript has use for both business users and developers. How can a business user use

In Part 1  we had covered the topics of understanding Azure Service Principals and how to create them. In this part we will look at using the Service Principals in a secure manner when creating Azure Automation Runbooks and carrying out AzureRM tasks. We will not get into the details of how to create a automation account in Azure. It is very simple to follow the Microsoft Docs  to create an automation account and also learn how to create a runbook and schedule it. We will now focus on the how-to of using an Azure Service Principal in our PowerShell script. In this example we will use the Password-based Service Principal for simplicity. Maybe I'll create another post for the certificate based service principal in a later update. Note: The Service Principal can be used as any other account in Azure. So, you can use it with RBAC across Resource Groups/Resources as might be necessary. Go to your Automation Account resource and scroll down to find "Credentials" in t

So you need to run a PowerShell script inside a Azure Automation account and the script uses AzureRM cmdlets. How would you authenticate? Do you use a user account? But the user account could have more permissions than what is actually required for your script, opening a whole discussion around security. I have also seen organizations create user accounts that are used as service accounts. But what does Microsoft say? "Automated tools that use Azure services should always have restricted permissions. Instead of having applications sign in as a fully privileged user, Azure offers service principals. " So what is an Azure Service Principal? An Azure service principal is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.  Service Principals offer 2 kinds o

SharePoint Realm is one of those things that is not discussed a lot in the SharePoint world, at least not until you are discussing oAuth and trust. In majority of cases, we are content with the default Realm ID that is set when we install SharePoint. What if some SharePoint administrator thought that it was perhaps cool to change the realm from GUID to any random string? Don't think its possible? Of course it is, just look closely at the Set-SPAuthenticationRealm cmdlet. Set-SPAuthenticationRealm [-AssignmentCollection <SPAssignmentCollection>] [-Confirm] [-Realm <String>] [-ServiceContext <SPServiceContextPipeBind>] [-WhatIf] [<CommonParameters>] Attribute Realm is a string and it allows an administrator to choose any string of his liking to be the new Realm ID. I just finished troubleshooting for a customer where the customer was unable to run any of the full-trust add-ins that they had on a new farm they had setup. The add-in