Skip to content
/

At the Ignite conference keynote Microsoft announced Bing for business. Winvision is one of the partners participating in the current preview.
With the public announcement of Bing for business, I’m now allowed to show you what the service is offering our company.
In the coming days I will be posting about several parts of Bing for business, starting with “branding”.

At the Ignite conference keynote Microsoft announced Bing for business:

A new intelligent search experience for Office 365 and Microsoft 365, which uses AI and the Microsoft Graph to deliver more relevant search results based on your organizational context.

As you might have heard at the end of the demo by Li-Chen Miller, Winvision was mentioned as one of the partners participating in the current preview.

With the public announcement of Bing for business, I’m now allowed to show you what the service is currently offering.
In the coming days I will be posting about several parts of Bing for business, starting today with branding.

Branding

You want the Bing for business search result to feel familiar for everybody in the company. Therefore, you can configure some settings that change the look and feel. Most notable the name and logo of the company and a recognizable color, just like you can in Office 365.

For our company, this it’s something like the following configuration:

This will make the search results in Bing look like this:
The content is stripped to not distract from the branding.

The Bing for business section is recognizable by the gray background bar.

From the settings, we recognize:

  1. The company name
  2. The company color
  3. The logo
  4. The favicon

Even when a Bing for business search result is shown in the sidebar, the company logo and color immediately pop out and make it recognizable as a business result:

If you are interested in receiving an invitation to participate in the private preview, visit http://aka.ms/b4bprivatepreview.

Filed under Office
Last update:
/

The other day I wanted to configure Application Logging on Blob Storage for a Web App Service and found out this needs a SAS URL. And this is something an ARM template can’t provide for you.
In this post, I will walk you through the necessary PowerShell code to run.

These days it’s normal to deploy and configure all aspects of your Azure Resources using the Azure Resource Manager and the accompanying ARM Templates. But sometimes you walk into a missing feature that’s is not (yet) available in the ARM system.
The other day I wanted to configure Application Logging on Blob Storage for a Web App Service and found out this needs a SAS URL. And this is something an ARM template can’t provide for you.

In this post, I will walk you through the necessary PowerShell code to run. For example, after your ARM template has been deployed. At the end of the post you will find the link to the source code.

The ARM template

In the ARM template, we deploy a Storage Account and a Web App Service.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "kind": "Storage",
            "name": "loremipsumstore",
            "apiVersion": "2016-01-01",
            "sku": {
                "name": "Standard_LRS"
            },
            "location": "[resourceGroup().location]"
        },
        {
            "type": "Microsoft.Web/serverfarms",
            "kind": "app",
            "name": "LoremIpsumAppService",
            "sku": {
                "name": "B1"
            },
            "apiVersion": "2015-08-01",
            "location": "[resourceGroup().location]",
            "properties": {
            "name": "LoremIpsumAppService",
                "numberOfWorkers": 1
            },
            "resources": [
                {
                    "type": "Microsoft.Web/sites",
                    "kind": "app",
                    "name": "LoremIpsumWebApp",
                    "apiVersion": "2015-08-01",
                    "location": "[resourceGroup().location]",
                    "properties": {
                        "name": "LoremIpsumWebApp"
                    },
                    "dependsOn": [
                        "[resourceId('Microsoft.Web/serverfarms', 'LoremIpsumAppService')]"
                    ]
                }
            ]
        }
    ]
}

The problem

When we configure the Application Logging to Blob Storage using the Azure Portal we see the following properties in the JSON of the Web App Service using the Azure Resource Explorer.

"applicationLogs": {
  "azureBlobStorage": {
    "level": "Verbose",
    "sasUrl": "https://loremipsumstore.blob.core.windows.net/webapp-logs?sv=2015-04-05&sr=c&sig=XXX...XXX&st=2017-05-29T22:00:00Z&se=2217-05-29T22:00:00Z&sp=rwdl",
    "retentionInDays": 30
  }
}

But secretly, the last two properties are stored in the AppSettings. When we look there we see the following 2 keys:

DIAGNOSTICS_AZUREBLOBCONTAINERSASURL    https://loremipsumstore.blob.core.windows.net/webapp-logs?sv=2015-04-05&sr=c&sig=XXX...XXX&st=2017-05-29T22:00:00Z&se=2217-05-29T22:00:00Z&sp=rwdl
DIAGNOSTICS_AZUREBLOBRETENTIONINDAYS    30

Setting AppSettings with an ARM template isn’t that hard. But the URL we need to set can’t be predefined and ARM templates don’t have support for the generation of a SAS URL.

Many ARM template samples do use SAS URLs, but always as a parameter. But how can you supply a parameter to a resource that might not yet exist? That’s the whole point of using the template.

So, the only option is to configure the Web App Service after running the deployment.

The solution

For this solution, we use PowerShell. This makes it easy for running this code in a VSTS or TFS release pipeline. But it can be used in any way you want to configure your environments.

Depending on how you run this script you might need to login first using Login-AzureRmAccount and select the Azure Subscription you want to use using Select-AzureRmSubscription.

The configuration is done in 6 steps.

  1. We get the Storage Account where we want to store the Application Logs.
    $sa = Get-AzureRmStorageAccount -ResourceGroupName "loremipsumresourcegroup"
                                    -Name "loremipsumstore"

  2. We make sure there is a container to store the logs. Because we can run the script multiple times, we ignore the error if the container already exists.
    New-AzureStorageContainer -Context $sa.Context
                              -Name "webapp-logs"
                              -ErrorAction Ignore

  3. Next, we generate the SAS token for the container. We use the same settings Microsoft uses when creating the link using the Azure Portal.
    $sasToken = New-AzureStorageContainerSASToken -Context $sa.Context
                                                  -Name "webapp-logs"
                                                  -FullUri
                                                  -Permission rwdl
                                                  -StartTime (Get-Date).Date
                                                  -ExpiryTime (Get-Date).Date.AddYears(200)

  4. We want to update the AppSettings as the configuration is stored there. But when you update the AppSettings, any setting not present in the update will be removed. Therefore, we first want to get all the existing AppSettings.
    $webApp = Get-AzureRmWebApp -ResourceGroupName "loremipsumresourcegroup"
                                -Name "LoremIpsumWebApp"

  5. Strangely the Set-AzureRmWebApp command does not accept the SiteConfig.AppSettings we got from the Get-AzureRmWebApp command. We need to create a Hash Table for this.
    To make sure the Application Settings keep the same order, we define the Hash Table as Ordered.

    $appSettings = [ordered]@{}
    $webapp.SiteConfig.AppSettings | % { $appSettings[$_.Name] = $_.Value }
    $appSettings.DIAGNOSTICS_AZUREBLOBCONTAINERSASURL = [string]$sasToken
  6. Now we can update the App Service using the Set-AzureRmWebApp command.
    Set-AzureRmWebApp -ResourceGroupName "loremipsumresourcegroup"
                      -Name "LoremIpsumWebApp"
                      -AppSettings $appSettings

Source code

The complete source code is available as GitHub Gist: Configure­AppService­ApplicationLog­To­BlobStorage.ps1 for reference.

/

When I recently was configuring an Azure AD application I couldn’t assign the delegated permissions for an Azure SQL Database. It did cost me a full day to find out the Azure Portal user interface has an unexpected user interaction when it comes to selecting APIs.

In this post, I’ll explain how you can find all APIs available for your application.

When I recently was configuring an Azure AD application I couldn’t assign the delegated permissions for an Azure SQL Database. It did cost me a full day to find out the Azure Portal user interface has an unexpected user interaction when it comes to selecting APIs.

In this post, I’ll explain how you can find all APIs available for your application.

The problem

When we want to integrate an application with Azure AD we need to register an app.
In my case I want to let a user access an Azure SQL Database using delegation. So, the database connection will be created impersonating the user account, not a generic service account.

To grant delegation permissions to an API we go to the Required permissions section of the Azure AD app:
Required permissions menu item

When we’ve created a new app there is not much showing yet, other than the default Azure AD delegated permission to sign in as the user:
Required permissions pane with default entry

We click on the Add button and choose the Select an API option:

Select an API menu item

Here we get a list of APIs to choose from. But our Azure SQL Database is not listed.
There is a search function, but entering SQL, like my colleague did, didn’t list any results.

This is where I started to search online if other people encountered the same problem. One of the few related posts is by Michael Collier: .
In his post he mentions not having the API listed:

Before you can continue, you need to have followed the prerequisites steps stated at the top of this post. You especially need to be sure you have created an Azure AD contained database user. If you fail to do that, you will not see “Azure SQL Database” in the list (as specified below).

But following all his steps didn’t make the API appear.

After wasting more time not finding any other related posts, adjusting multiple settings, and recreating Azure AD apps, I suddenly found a lead that pointed me in the right direction

The solution

One of the apps I created was named AzureSqlAppTest. Because the list of registered apps is quite long I wanted to use the search function and I entered the word SQL.
To my surprise no results. Entering AzureSQL did show my app.

The search function in the Azure Portal is acting only as a Begins With filter!

Desperately, I tried this trick on the API list as well. Maybe the API search function doesn’t show SQL related APIs because the name doesn’t start with SQL.

Instead of SQL I entered Azure in the search box, and to my amazement: a whole new list of never-before-seen APIs showed up, including our Azure SQL Database:
Select an API pane listing many APIs that where hidden

There are many more APIs available in the Azure Portal, there is just no indication in the UI!

After re-reading Michael Colliers blog post, I found he did mention this at the end of one of the steps:

3. Add a new required permission and select Azure SQL Database as the API. You’ll want to search for “azure” to get “Azure SQL Database” to appear in the list.

Now we can configure our app, and everything will work as expected.

The conclusion

Just because the Azure Portal UI doesn’t give any hint there are many more APIs hidden behind the search function, I wasted a lot of good time.
I hope this post will prevent you from wasting yours, and I hope the Portal UI will improve.

Filed under Azure
Last update: