Forem: Tidjani Belmansour, Ph.D.

Managing your Azure environment using natural language with Azure Copilot

Tidjani Belmansour, Ph.D. — Wed, 17 Dec 2025 02:52:27 +0000

“Hey, are you awake? The cheese order app is down.”

— Message received at 03:07 from Leo, Azure admin at the legendary Couic-Couic Cheese Factory.

If you’ve ever jumped between Application Insights, Log Analytics, and Azure Monitor like a caffeine-fueled ninja in the middle of the night, you know the drill: logs, metrics, correlations, hypotheses, and that little anxiety slider creeping up by the minute. Manual troubleshooting is the #1 time thief in cloud operations. And when it’s not an incident, it’s a month-end report asking why your Azure bill went up 15% (“Did someone leave a Dev-XL-I’ll-Test-But-Forget VM running?”).

Welcome to the reality of cloud teams. Good news: Azure Copilot is here to bring simplicity, speed, and a little smile back into the game.

What Exactly Is Azure Copilot?

Azure Copilot is the AI assistant built into Azure that lets you manage your environment in natural language. You describe what you want to do, and it helps you design, implement, operate, optimize, and troubleshoot your resources—right inside the Azure Portal, the mobile app, or via CLI.

Leo sums it up perfectly:

“It’s like having a teammate who knows my Azure subscription, speaks my language, and never forgets where that Network Security Group named NSG-final-v3-definitive is hiding.”

Why Copilot and Not Just Any Chatbot?

Sure, you could ask any AI “Why is my app crashing?” But the game-changer here is context. Azure Copilot sees your environment (within your permissions because with great power comes great responsibility), understands your resources, their state, and configuration, and cross-references this with best practices and documentation. The result? Actionable answers, specific to your tenant and your workloads.

Five Superpowers of Azure Copilot (Tested and Approved by Leo)

1) Design

“For a high-availability ordering site with 1-hour disaster recovery, what should I use?” Copilot suggests an architecture (availability zones, replication, Front Door/Traffic Manager, etc.), explains service choices, and their impact on SLA/HA/DR.

2) Implement

“Generate a **Bicep* script for App Service + Key Vault + alert.”* Copilot can create scaffolding, fill parameters, and apply best practices. Same for Terraform if that's where your preference is.

3) Operate

“List all **VMs* with RDP open, web apps with expired SSL certificates, blobs that are publicly accessible, and resources outside Canada.”* Copilot gives you targeted inventories, detects performance anomalies, and saves hours of portal spelunking.

4) Optimize

“My bill went up 15% last month. Why?” Copilot analyzes cost drivers, forecasts next 3 months, suggests better SKUs, and flags forgotten environments. It also helps harden compliance posture via Policy.

5) Troubleshoot

“I’ve got this weird error on my App Service—what does it mean and how do I fix it?” Copilot explains the error and guides resolution (config, dependencies, quotas, diagnostics). Goodbye to “why the heck won’t my script work??” moments.

Is It Free?

Yes, current features are free. Microsoft says future capabilities might come with a cost—but nothing concrete yet. For now, enjoy!

Security: Let’s Talk About It

Adopting an AI assistant raises legit questions: access rights, data isolation, traceability, compliance. Azure Copilot runs within Azure’s security model, respects RBAC, and only shows what you’re authorized to see. This is often the biggest adoption hurdle—so involve your security team early.

In a future article, I will cover more about security mechanisms but for now, remember that Azure Copilot can only perform actions that you are allowed to perform and see data that you are allowed to see.

How Do You Access It?

Azure Portal: Azure Copilot panels appear in supported contexts.
Azure Mobile App: Handy for quick checks on the go.
CLI: For terminal lovers, Azure Copilot accelerates workflows and suggests commands. This happens through AI Shell (more on that in an upcoming post).

Will Copilot Steal My Job?

Leo wonders the same (and so do we). No. Copilot doesn’t replace understanding business priorities (or politics…). It amplifies your impact by removing technical friction, so you can focus on what matters: service quality, security, compliance, speed-to-market, and collaboration.

Think of it as an assistant: it does real work, but you stay in control.

Couic-Couic Cheese Factory Use Cases (Almost Real)

Incident at 03:07: Ordering app is slow.

Copilot spots CPU spike on App Service, correlates with a function looping over a public blob full of HD cheese glamour shots.

👉 Fix: Throttle + cache + CDN, lock blob, update Policy.

🕒 Time saved: 90 min. Stress avoided: immeasurable.
Month-end +15% bill:

Copilot isolates cost increase to dev/test (oversized SKU, permissive autoscale), suggests right-sizing and shutdown schedule.

👉 Fix: Autoscale tuning, cost center tags, budget alerts.

💰 Savings: Significant. Finance loves Leo.
Canada-only audit:

Copilot lists resources outside CA, expired certs, and generates a remediation plan.

👉 Fix: Migration, cert renewal, stronger Policy.

What You Can Do Today

Ask concrete questions
- “Show me web apps with expired SSL.”
- “Which VMs have RDP exposed?”
- “Generate Bicep for Key Vault + App Service + CPU alert.”
Request explanations + fixes
- “I have error X on my Function App—why and how to fix?”
Optimize governance and costs
- “Why did my bill increase and how to reduce it?”
- “Forecast my costs for the next 3 months.”
- “Help me harden Policy compliance.”
Use it in the right context
- Portal for visibility and actions.
- Mobile for quick checks.
- CLI for scripted workflows.

In Short

With Azure Copilot, you can:

Get precise insights into your environment.
Discover and learn new Azure features without having 12 tabs open.
Perform complex or tedious tasks simply by describing them in natural language.

Azure Copilot doesn’t replace human expertise—it unlocks it. And it gives Leo (and you) more peaceful nights.

Your Turn

Have you tried Azure Copilot yet?

What was your first “aha moment”?

Share it—and let’s turn your use cases into reusable Copilot prompts playbooks.

🎁 Prompt Cheat Sheet

Design

“Suggest an architecture for a high-availability web app with DR in 1 hour.”
“What Azure services should I use for SLA 99.99%?”

Implement

“Generate a Bicep script for App Service + Key Vault + alert.”
“Create Terraform for a VM with NSG and diagnostics enabled.”

Operate

“List VMs with RDP open.”
“Show web apps with expired SSL certificates.”
“Find blobs that are publicly accessible.”

Optimize

“Why did my Azure bill increase by 15% last month?”
“Forecast my costs for the next 3 months.”
“Suggest a better SKU for VM xyz.”

Troubleshoot

“Explain this error on my Function App and how to fix it.”
“Why is my App Service slow and what can I do?”

Do you really need a landing zone?

Tidjani Belmansour, Ph.D. — Wed, 03 Sep 2025 15:34:31 +0000

If you've ever worked on a cloud computing project, chances are you've heard of a "landing zone."

But what is it, and do you really need one? That's what we are going to explore in this article.

A landing zone… what is that??

A landing zone is a concept you'll hear mostly in the context of cloud computing projects. It's a reference architecture designed to provide a secure, compliant, governed, and controlled environment for your workloads.

This allows you to establish a solid foundation of governance, compliance, security, and control that will benefit all your workloads accelerating innovation while ensuring organizational flexibility.

Accelerating innovation… but how? Because you don’t have to implement security, governance, or compliance controls within your workloads. These are implemented at the landing zone level. While you may need to implement additional controls on certain workloads, your landing zone will ensure that no compromises have been made around the workload itself if you do nothing.
Ensuring organizational flexibility… really?! Yes, a landing zone allows an organization to be flexible, resilient and responsive, both for major developments and when integrating new needs or complying with market standards. This flexibility is achieved through modularity (in particular the establishment of environments isolated per team and over which these teams have almost total control); the ability to deploy types of services according to need and independently of the needs of other teams or departments; the automation of deployments; and finally, the centralization of governance to ensure compliance and consistency of the cloud environment.

A landing zone… for what purpose??

A landing zone helps address the following challenges in your cloud adoption:

Cloud governance: through centralized control of resources, standardization of configurations, application of policies, compliance with regulatory requirements.
Integrated security: through segmentation, securing communications, identity and access management (RBAC), continuous monitoring, isolation of environments (prod, dev, test).
Cost optimization: through cost management via clear distribution between business lines, using the appropriate services and right-sizing them, limitation of costly data transfers thanks to optimized network topology.
Agility: through rapid adaptation to growth, organizational changes, and technological changes.

To achieve this, a set of cloud services must be deployed and configured, such as one or more firewalls, VPNs, a SIEM, domain controllers, a log ingestion and analysis tool, a monitoring solution, an alerting solution, identity and access management tools, network monitoring tools, backup and DR tools, a policy implementation and enforcement solution, etc.

But wait a minute... a landing zone can be expensive!

Yes, a landing zone isn't free. Depending on the adopted topology and setup, it can cost anywhere from a few dozen dollars to several thousand dollars per month!

Is it expensive, though? It's all relative. Let's say your landing zone costs $4,000 per month. But thanks to it, your data and workloads are protected and backed up. In your eyes, is data theft worth saving these $4,000 (with all the bad press and the loss of customer trust and possibly market share)? Whatever your answer is, you have your answer 😉.

So, we can think of landing zone costs like insurance costs: we don't like paying them, but we're glad to have that insurance in case things go wrong😊.

An important thing to keep in mind regarding landing zone costs is that these costs are generally passed on to the consuming lines of business, either as an equal split (i.e., the landing zone costs are divided by the number of business units consuming it) or based on a pro rata usage (although the latter might be more difficult to assess).

Landing zones topologies

In the previous section, you heard me refer to landing zone topologies. But what are they?

A landing zone topology refers to how the cloud architecture and components are organized, segmented, and interconnected to meet business needs. The topology therefore defines the logical structure of the cloud environment, resource segmentation, network flows, access rules, and overall governance.

Each provider offers different topologies (via their Cloud Adoption Framework). These topologies reflect the most common needs for different business sizes and complexities. On the Microsoft side, the best-known are "Hub-and-Spoke" and "Virtual WAN."

As an example, here's what the Hub-and-Spoke topology may look like:

A landing zone, how do we set it up?

As with any cloud workload, there are different ways to set up a landing zone.

It's possible to set it up through click-click in your preferred cloud platform's portal, but this isn't the most recommended method because it's manual, prone to errors and leaves no trace (i.e., it's difficult or impossible to track who did what and in what order).

Cloud providers also provide what they call "accelerators" for setting up a landing zone, either automatically or semi-automatically. These accelerators work very well as long as they align with the topologies offered by these providers (usually via their Cloud Adoption Frameworks). However, customizing these accelerators for specific needs can be complex, particularly because they require a learning curve.

The final option (the one that offers the greatest degree of flexibility and customization) is to develop your code yourself. This is referred to as an "infrastructure as code" approach, in which you script your cloud infrastructure using a technology specifically designed for this purpose. Several technologies exist, and you've probably already heard the name of one of them. These include Terraform, Bicep, Pulumi, Ansible, CloudFormation, ARM Templates, and more.

Finally, note that in a corporate context, the implementation of the landing zone is the responsibility of a dedicated team, generally called the "cloud platform team," which works closely with the CCoE (Cloud Center of Excellence) to define it.

A landing zone is a living organism!

Rest assured, it's neither an alien nor a zombie! 😁

However, a landing zone is a very living organism. We saw earlier that a landing zone can have different topologies. What we didn't mention is that it evolves to adapt to changing business needs. One of the most common examples in the Azure world (but this remains true for other cloud platforms) is evolving the landing zone to adopt AI or AVS (Azure VMWare Solution) services.

Note that it's not just the landing zone topology that may need to evolve. In some cases, this evolution may involve authorizing new services (or restricting those that are no longer used), or implementing new compliance controls, resulting from changes in regulations in your industry. This is why it's recommended to use an “infrastructure as code” approach when implementing a landing zone, as it facilitates its evolution while keeping track of the changes made.

Oh! And one more thing... Just as a landing zone is alive, so is the code used to implement it. Whether you use an accelerator provided by your cloud provider of choice or have developed your own code, remember to periodically (at least once a year) review and update it according to new standards and APIs, if applicable.

I use the cloud for personal needs. Do I still need a landing zone?

In that case, you certainly don't need a full-fledged, complex landing zone.

However, for the sound management of your cloud environment, you still need to implement minimal governance, which consists of having security policies in place, budgets set up, MFA configured and enabled, assigning only the required RBACs, and monitoring to ensure security and control of your cloud environment without the complexity of a corporate landing zone.

Now onto you: do you think a landing zone is useful?

Automating your Azure infrastructure with Pulumi

Tidjani Belmansour, Ph.D. — Wed, 08 Sep 2021 14:03:21 +0000

Pulumi allows developers to do infrastructure as code using their favourite programming language.

If you don't know what Pulumi is or haven't gave it a try yet, then join me for a kick start:

https://www.youtube.com/watch?v=eH8-Z_j6lvQ

This session is presented to you by Azure Back To School 2021:

The Azure Back To School event compiles an awesome list of Azure content created by wonderful people and I had the great pleasure to be part of it.

See the full schedule here: https://azurebacktoschool.tech

Let's keep in touch

You can reach me on Twitter.

See you soon !

Manage your data retention policies with Azure Storage Lifecycle Management

Tidjani Belmansour, Ph.D. — Fri, 26 Mar 2021 01:07:14 +0000

This article is part of the Azure Spring Clean initiative

I would shoot out a big thank you to Joe Carlyle and to Thomas Thornton for giving me the opportunity to be once again part of this incredible journey. Thanks Joe!

If you're not yet aware of the Azure Spring Clean initiative, please head to https://www.azurespringclean.com where you'll find out more great content presented to you by awesome people. You can also share your excitement on Twitter by using the hashtag #azurespringclean.

Okay. Now, let's get to our topic for today!

Intro

You may know it by now: data is what fuels applications and services. In order to feed our applications and services with the data they need to perform their operations, we need to store that data somewhere, may it be in a database, a directory or somewhere else. On Azure, a storage account is often considered as an option for storing data since it provides us with a reliable, cost-effective, easy-to-use-yet-powerful storage mechanism.

However, and regardless of the storage mechanism we rely on in order to store our data, it worth mentioning that such data isn't used in the same way nor at the same frequency. For that matter, the Azure Storage Account service provides us with 4 services, namely: Blob, Files, Queues and Tables which allow us to store different kind of data and work with it in different fashions. For more information on these four services, you can refer to the official Microsoft documentation for the Azure Storage Account service.

When it comes to storage access tier, the Azure Storage Account service provides us with 3 options:

Hot: Optimized for storing data that is accessed frequently;
Cool: Optimized for storing data that is infrequently accessed and stored for at least 30 days;
Archive: Optimized for storing data that is rarely accessed and stored for at least 180 days with flexible latency requirements, on the order of hours.

Generally speaking, data in the Hot access tier are more expensive to store than data in the Cool access tier which, in turn, is more expensive to store than data in the Archive access tier. This is also true when it comes to the Azure Storage Account service.

So, you may ask, we should always use the Archive access tier when it comes to storing our data, right?
Well, it's not that simple...

Although storing data in the Archive access tier is the cheapest, it is the most expensive when it comes to retrieving that data. And when I say "more expensive", I'm not only referring to the monetary cost of the transaction to retrieve that data but also to the time required to retrieve it. For example, it might take up to several hours to retrieve data that is stored in the Archive access tier. Thus, you definitely don't want to retrieve data from the Archive access tier if the request was initiated by a user through your web application, knowing that this user is waiting in front of his/her screen to be presented with these information!

So, why would I care about lifecycle management at all?!

Right now, you might have totally changed your mind and thinking that you should always rely on the Hot access tier. Am I right?
Well, once again, it's not that simple...
It is still worth to set the appropriate the right access tier depending on the context we're in. Note that you don't necessarily have to choose only one access tier for ALL the data you store in an Azure Storage Account instance. You may (and should) fine tune the access tier for each piece of data.

Another factor to take into account is that, as time is passing by, a given data might need to be set to a different access tier.
For example, let's say that my application is collecting the sales data for a given store and processing it to, let's say, evaluates inventory provisioning for the most in-demand products. I would probably need to use the Hot access tier for that data since I'm expecting to use it quite often in the upcoming days. However, the sales data of the last quarter or even last year might not need to be accessed so often. Thus, the Cool access tier would probably be more appropriate. Now, when it comes to the sales data of the last 5 or 10 years, then chances are that the Archive access tier will be more appropriate since you'd probably not need to access that data so often but still want to keep it for any reason, shall it be for legal reasons, for later ML processing of that data or simply... "just in case".

How to set up lifecycle management?

We could definitely write some code or script for that matter (we can think of an event-driven application such as an Azure Functions, a Logic App or an Automation Runbook). However, it is interesting to note that the Azure Storage Account service provides us with a functionality that does just this. This functionality is called "Lifecycle Management".

First, you need to know that the lifecycle management feature applies to Azure Storage Account instances of type General Purpose V2:

If yours is of type General Purpose V1, you can go to Configuration and click Upgrade:

Okay, now let's set up a lifecycle management policy!

Here's our use-case scenario:
* we may want to change the access tier of a blob from Hot to Cool if the blob hasn't been modified for the last 14 days
* we may want to change the access tier of a blob from Cool to Archive if the blob hasn't been modified for the last 30 days
* we can also define a rule to delete the blob after a given period of time if that's want we need but in this case, we won't.

The Lifecycle management feature can be found under Blob service.
Once we get there, we simply click on Add a rule.

In the Details window, we can set a name for our rule and decide the scope and type of the blobs to which the rule should apply.
Note that we can access the Filter set window only if we choose Limit blobs with filters option:

The Base blobs window is where we apply the rules we've defined in our scenario above. We can do that by creating as much if-then blocks as needed.

The Filter set window is where we indicate which blob or container these rules apply to.
We can specify multiple entries to the "Blob prefix" in order to apply the defined rules on multiple blobs and/or containers within that storage account.

There's a catch however: if you don't specify at least one value in the "Blob prefix" list, then the rules will apply to every blob in the current storage account instance! Thus, you'd want to pay a special attention to that.

Our Azure Storage Account instance has three containers, namely: "images', 'reports' and 'invoices':

We want to apply this new rule only to the blobs located in the 'invoices' container. Thus, we define the Blob prefix as follows:

We finally click the Add button and our new rule is created and enabled!

Special notes

It is worth mentioning that, although we will demonstrate the creation of the lifecycle management rules right from the Azure Portal, we could also create them using SDKs or CLI (e.g. Azure CLI or PowerShell).

Another thing to mention is that, at the end of the day, these rules translate into a JSON format. Thus, we can grab that JSON, store it somewhere (e.g. in our source code management of choice) and reuse it on another project.

We can enable or disable the rules we've created or we can delete them:

At the time of this writing, we can only define rules based on the last modification date of the blobs.

When does the rule applies?

The rules are applied once every 24 hours. Thus, if we create a new rule or modify an existing one, it may take up to 24 hours for it to be executed.

At the time of this writing, there is no way to define a schedule for when the rule should be executed nor to execute it in real time.

As a conclusion...

Today, we saw that Azure Storage Lifecycle Management provides us with an easy and automated way to set the storage access tier of our data to the right value and at the right time without involving extra development nor extra services.

Let's keep in touch

You can reach me on Twitter.

See you soon !

Disconnect from your Azure account when inactive

Tidjani Belmansour, Ph.D. — Sun, 03 Jan 2021 23:11:58 +0000

In my previous posts and talks, I've shown you various techniques to strengten the security of your Azure environment.

However, there is one little thing that if we are not careful about, could compromise the security of our Azure environment. That little thing might be so obvious that it's often forgotten. That little thing is to disconnect from our Azure account when we're not using it.

You've may noticed that when you go back to your workstation after few hours (or few days?), and navigate to the Azure portal, you're still logged in to your account. Can you imagine what would happen if someone used your workstation while you were away? If you only have Reader permissions, then no big deal. But imagine if you have administrative permissions (e.g. Contributor or Owner)! That could be harmful.

Fortunately, there's a little hidden gem in the Azure portal that lets you automatically be disconnected from your account after a given period of time of inactivity.

To configure it, simply do this:

To be honest, I'm wondering why this feature isn't enabled by default!

In conclusion...

Today, we have done one more step toward a more secured Azure environment by leveraging a hidden gem in the Azure portal.

Let's keep in touch

You can reach me on Twitter or LinkedIn.

See you soon !

Target .NET 5 in Azure App Service

Tidjani Belmansour, Ph.D. — Wed, 11 Nov 2020 02:40:31 +0000

Today is a big day: .NET 5 has officially been released as part the .net conf. Awesome!

What's more awesome is that we can now deploy .NET 5 applications on Azure App Service. And what's more than "more awesome" is that we can do that for both Windows and Linux App Services. Isn't that awesome? ;)

Targetting .NET 5 in an App Service

If you create a new web app and check the list of available runtimes, you'll see .NET 5 (Early Access) under the .NET category:

Early access ?!

Early access is a new feature of Azure App Service that will allow us to rapidly have access to the latest releases of various runtimes and SDKs without having to wait for an App Service release cycle to include that support. This is not only for .NET but also for other supported programming languages such as Python and Node.

As of today (November 10, 2020), Early access has some limitations, one of which is that Application Insights is not supported for .NET 5 applications.

To learn more about Early access, visit: https://github.com/Azure/app-service-linux-docs/blob/master/Runtime_Support/early-access.md

What about existing web apps?

If you're running a Linux-based App Service, go to Configuration then to General settings and, under Stack settings, select .NET and you'll be targetting .NET 5 (both Major version and Minor version will adjust to use .NET 5). Don't forget to hit Save:

If you're running a Windows-based App Service, the procedure is slightly different. Go to Configuration then to General settings and, under Stack, select .NET and under .NET Framework version, select .NET 5:

It's interesting to note that when switching runtimes, the Early access suffix isn't mentioned...

In conclusion

Starting today, we can use all the goodness provided by .NET 5 in our Azure App Services and it's as easy as selecting .NET 5 as our App Service's runtime.

Let's keep in touch

You can reach me on Twitter or LinkedIn.

See you soon !

What Linux distribution is Powering Azure App Service?

Tidjani Belmansour, Ph.D. — Fri, 30 Oct 2020 19:14:51 +0000

You probably know by now that you can have Linux-powered App services.

But, have you ever wonder what Linux distribution is powering that App Service?

Looking at the Environment section of the Kudu console won't help:

Well, wonder no more! Simply open a WebSSH terminal:

And type this command:

cat /etc/os-release

And you'll get the requested information:

Easy, right? ;)

In conclusion...

Today, we have lifted the veil on some part of the magic that powers the Azure App Service for Linux offering which is what version of Linux this service is running on.

Let's keep in touch

You can reach me on Twitter or LinkedIn.

See you soon !

Automate the installation of the Azure Portal Desktop app

Tidjani Belmansour, Ph.D. — Sun, 25 Oct 2020 22:15:48 +0000

The Azure Portal Desktop application is great. I love it and I use it!
It avoids me having the open the Azure Portal in different browsers and have to deal with in-private windows and "public" windows.

If you don't know what I'm talking about, you can check out my article (in French) about that desktop app here:
http://espacenuagic.com/2019/05/15/azure-portal-desktop-app/

Why would I want to automate that installation?

If you want to automate the configuration of your dev boxes (for example, if you want to provide a common script to help all you developers to set up their development environment), then you'll certainly look for a way to automate the installation of the Azure Portal desktop application.

Ok... So, how do I do that?

Simple, just use that script:

$url =  'https://portal.azure.com/App/Download?acceptLicense=true'
$outputLocation = $env:USERPROFILE + '\AzurePortalInstaller.exe'

$progresspreference = 'silentlyContinue'
Invoke-WebRequest $url -OutFile $outputLocation
$progressPreference = 'Continue'

& $outputLocation /Q

Basically, all that script does is to download the installation package and runs it in quiet mode.

As a conclusion...

Today, we've learned that we can automate the installation of the Azure portal desktop app. This might be useful if you want to automate the configuration of your dev boxes.

Keep the discussion

You can reach me on Twitter or LinkedIn.

See you soon!

Manage Azure Service principal's credentials expiry

Tidjani Belmansour, Ph.D. — Fri, 02 Oct 2020 16:52:32 +0000

What? How? When? Why?... What?!

Service principals are great to give an identity to an application and set its permissions. Using a service principal, we can, as an example, restrict access for an application to other resources (such as a database) and control what it can do on that database in a more granular way.

Service principals are also great when setting a service endpoint connection in Azure DevOps for example, so you can deploy/configure your Azure resources from within your pipelines using ARM.

However, when you create a service principal, its credentials are by default valid for one year. This is for security reasons, so you don't forget about existing service principals that are hanging there forever and possibly creating a security breach in your infrastructure.

Why should I care?

You should! Because if you don't, your services that rely on service principals for authentication and authorization may just stop working.

In the above scenario of the service endpoint connection in Azure DevOps, your pipelines executions will fail due to the lack of the required permissions.

How do I check for the credentials expiration date of my service principal?

You can do that by using those two simple commands:

$sp = Get-AzADServicePrincipal -DisplayName $myServiceprincipalName
Get-AzADSpCredential -ObjectId $sp.Id

How to deal with that?

Depending on whether your service principal already exists or not, the procedure is slightly different.

Setting the expiration date at the creation of the service principal

If you haven't yet created your service principal, here's how to set a custom expiration date for it during its creation.

Here, we create a service principal named totoSP with the role Reader and we ensure the password will be valid for 150 years. Seems weird (and it is actually) but it's just for the sake of the demo ;) :

$start = get-date
$end = $start.AddYears(150)

New-AzADServicePrincipal -DisplayName 'totoSP' -Role Reader -StartDate $start -EndDate $end

Extend the expiration date for an existing service principal

If your service principal already exists (whether its credentials have expired or not yet), you can set a custom expiration date using the following commands.

Once again, we ensure the password will be valid for 150 years which seems weird (and it is actually) but it's just for the sake of the demo ;) :

# Get the Id of the service principal
$sp = Get-AzADServicePrincipal -DisplayName $myServiceprincipalName

# Set new password with extended expiration date
$start = get-date
$end = $start.AddYears(150)
$credentials = New-AzADSpCredential -ObjectId $sp.Id -StartDate $start -EndDate $end

In case you need that new password (e.g. in order to update your service endpoint connection in Azure DevOps), you can use these commands. Be careful however, you can only use them in the same PowerShell session in which you created that password:

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($credentials.Secret)
$UnsecureSecret = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

Write-Host $UnsecureSecret

The previous script will generate a random password and use it for the new, updated credentials.
If you want to specify your own password, you can do that instead:

$SecureStringPassword = ConvertTo-SecureString -String "@zuR3_R0ck$!!!!" -AsPlainText -Force
New-AzADSpCredential -ObjectId $sp.Id -StartDate $start -EndDate $end -Password $SecureStringPassword

As a conclusion...

Today, we've learned that Azure service principal's credentials have an expiration date. We also learned how to deal with that.

I hope that you found it valuable.

Keep the discussion

You can reach me on Twitter or LinkedIn.

See you soon!

the Azure Quebec community is now on YouTube!

Tidjani Belmansour, Ph.D. — Wed, 26 Aug 2020 00:13:05 +0000

Hey there!

Some of you may already know that I am the co-organizer of the Azure Quebec Community.

But did you know that we have a YouTube channel?

Since the introduction of the containment and social distancing measures, we started to run our meetings in a virtual mode. We therefore recorded the sessions and we are making them available on YouTube.

To watch or re-watch these sessions, follow this link.

Also, if you want to give a presentation on anything Azure related, please let me know.

See you soon !

Azure App Service and your app settings

Tidjani Belmansour, Ph.D. — Mon, 20 Jul 2020 15:00:40 +0000

When developing our .NET applications, we use to rely on web.config or appsettings.json files to store our application configuration settings and/or connection strings.

Once we deploy our application to Azure App Service (let's say a web app), we can "override" that configuration by adding appsettings and/or connection strings to the Configuration section with the same keys and different values. Since this section has precedence over the configuration files, the values in this section will be utilized.

What's the problem with this approach?

Apparently, there's no problem and if you do things correctly, there will probably never be a problem.

However, if you forget to specify a given app setting in the Configuration section or if you mispell its key, then it is the value stored in the configuration file (web.config or appsettings.json) that will be utilized instead of the one from the Configuration section.

I want a demo!

To illustrate that situation, let's assume that we have a web application that displays the value of an app setting. Nothing fancy here but it will suffice to illustrate the point.

When running the code on the local dev box, this looks like this (as you've may expected it):

Yes, I'm using Visual Studio for Mac which I like very much.

Now, let's deploy our web application to azure. Without any surprise, the message is still read from the appsettings.json file:

Okay. Now, let's add that app setting in the Configuration section of the web app with a different value. Then, the displayed value isn't coming from the appsettings.json file anymore but rather from the Configuration section of the web app instance:

Okay. Now comes the (not so) fun part!
If we forget to define that app setting or if we mispell it in the Configuration section of the web app instance, the value that will be shown is the one coming from the appsettings.json file (in this example, I purposingly "forgot" the H from the name of the app setting):

How can we avoid this problem?

There might be many ways to avoid such a tricky issue. The easiest one I found is to set the "Build action" property of your appsettings.*.json files to "None" and set the "Copy to Output Directory" property of these files to "Never":

The screen capture above also illustrates what the csproj will look like after updating these properties.

Thus, if the app setting is not defined in the Configuration section of the web app instance, the obtained value will be null. Your code is probably already doing such a null check. In my case, I've decided to display an error message if this situation happens:

Please note that doing so still allows you to use the appsettings.*.json files when running the application on your local dev box. They simply won't be published to Azure anymore.

It is also important to note that if the appsettings.*.json files have been previously deployed to your Azure App Service instance, a new deployment (after updating the above properties) won't remove them. You'll have to find a way to remove them. You can, for example, use "App Service Editor" to manually delete them.

In conclusion...

Today, we saw that given the fact that App Configuration in Azure App Service has precedence over the web.config/appsettings.json, it may introduce some unwanted and unnoticed side effects. We also discussed one way to address this situation.

Let's keep in touch

You can reach me on Twitter or LinkedIn.

See you soon !

Azure Cloud Shell: Use PowerShell in Bash

Tidjani Belmansour, Ph.D. — Fri, 19 Jun 2020 14:50:30 +0000

A quick one today...

I quite often hear this complaint: "I hate having to switch Cloud Shell from Bash to PowerShell to use cmdlets.". Well, you don't have to!

In fact, you can invoke the PowerShell Core interpreter right from within the Bash command-line in Cloud Shell. Simply type:

pwsh

And you'll fire off the PowerShell Core interpreter.

Once you're done and you want to go back to the Bash command-line, simply type:

exit

And you'll exit the PowerShell Core interpreter.

Simple, isn't it? ;)

As a conclusion

Working with the command line is essential when it comes to automation. Knowing that you can combine the power of Bash and PowerShell together will help you do great things.

Let's keep in touch

You can reach me on Twitter or LinkedIn.

See you soon !