Author: Manjunath

“Life is about passions. Thank you for sharing mine” -- M. Schumacher
Azure, Azure Integration Services

Azure Logic Apps & Service Bus: When Do You Need the ‘Manage’ Claim?

Manjunath

Ever wondered why your Azure Logic Apps sometimes fail to process messages consistently from a Service Bus queue? If you’ve run into issues with scaling, missing permissions, or unexpected failures, you’re not alone.

One of the key reasons for these inconsistencies is whether runtime scaling is enabled or disabled. And a major factor that affects this is the ‘Manage’ claim in your Service Bus connection string.

Understanding the Role of Runtime Scaling

Azure Functions that process messages from Service Bus queues can scale dynamically based on queue length. This is controlled by runtime scale monitoring. Whether you need the ‘Manage’ claim depends on whether this setting is enabled or not.

When Runtime Scaling is Enabled – ‘Manage’ Claim is Required

  • When runtime scaling is ON, Azure needs to check the active message count to decide whether to scale up.
  • To get this information, the system queries the Service Bus queue metadata.
  • Without the Manage claim in the connection string, the system cannot access queue details and fails to determine the active message count.

And that’s when you start seeing errors like this:

“Connection string does not have ‘Manage Claim’ for queue ‘[Queue_Name_Here]‘. Unable to determine active message count.”

Since it can’t retrieve the queue length, it falls back on alternative metrics:

“Failed to get queue description to derive queue length metrics. Falling back to using first message enqueued time.”

When Runtime Scaling is Disabled – ‘Manage’ Claim is NOT Required

  • When runtime scaling is OFF, Azure Functions do not need to query the queue length.
  • The function still processes messages as they arrive, but without automatic scaling.
  • Since it doesn’t check queue metadata, the Manage claim is not needed.

This is why, in some cases, disabling runtime scaling makes things appear to work more reliably. There’s no interference from scaling decisions, and messages just get processed at a steady rate.

How to Avoid Failures and Keep Things Running Smoothly

If You Want Scaling (Runtime Scaling ON)

  • ✅ Make sure your Service Bus connection string has the Manage permission.
  • ✅ Enable runtime scale monitoring in Azure Function settings.
  • ✅ Keep an eye on scaling behavior in Application Insights to avoid thread pool starvation.

If You Don’t Need Scaling (Runtime Scaling OFF)

  • ✅ No need for the ‘Manage’ claim—just Listen and Send permissions are enough.
  • ✅ Adjust function concurrency settings to control the processing rate manually.
  • ✅ Monitor your Service Bus queue to ensure messages don’t pile up.

By understanding how runtime scaling and permissions interact, you can avoid frustrating failures and keep your Azure Logic Apps running smoothly. Whether you need scaling or just steady processing, configuring things the right way makes all the difference.

Nutshell Series

Troubleshooting SFTP and HTTPS Connectivity from Azure Logic Apps and Function Apps

Manjunath

When working with Azure Logic Apps or Azure Function Apps, you may encounter connectivity issues when integrating with SFTP servers or HTTPS endpoints. This guide provides troubleshooting steps using tnc, tcping, ssh, and openssl commands.

1. Troubleshooting SFTP Connectivity

Step 1: Check Network Connectivity

To ensure that the SFTP server is reachable, use tnc (Test-NetConnection) and tcping:

# Using Test-NetConnection (PowerShell)
tnc <sftp-server> -Port 22

# Using tcping (Command Prompt)
tcping <sftp-server> 22

Common Errors and Fixes:

  • Request timed out / Connection refused: Indicates a firewall or network security group (NSG) restriction. Investigate network configurations.
  • No route to host: The destination might be unreachable due to VPN, VNET, or firewall restrictions.

Step 2: Test SFTP Authentication and Encryption

To verify authentication and encryption mechanisms, use SSH in verbose mode:

ssh -o BatchMode=yes -v -p 22 <sftp-server>

Common Errors and Fixes:

  • Permission denied (publickey, password): Verify credentials and authentication methods.
  • Cipher exchange errors: Indicates firewall or network-related issues; check NSG rules and firewall settings.
  • No response from the server: Indicates possible blocking due to outbound restrictions from Logic Apps or Function Apps.

2. Troubleshooting HTTPS Connectivity

Step 1: Check Network Connectivity

Use tnc and tcping to check if the HTTPS endpoint is accessible:

# Using Test-NetConnection (PowerShell)
tnc <https-server> -Port 443

# Using tcping (Command Prompt)
tcping <https-server> 443

Common Errors and Fixes:

  • Connection refused / Request timed out: Indicates network issues such as NSG rules blocking outbound connections.
  • No response from server: Could be due to incorrect routing or firewall policies.

Step 2: Verify SSL/TLS Handshake and Certificate

Use OpenSSL to test TLS handshake and certificate validation:

openssl s_client -connect <https-server>:443

Common Errors and Fixes:

  • Unable to verify certificate: The SSL certificate might be missing or untrusted; check if the certificate is valid and trusted by Azure.
  • TLS handshake failure: Possible cause is a mismatch in TLS versions; ensure that Logic Apps and Function Apps support the required TLS version (1.2+ recommended).
  • Certificate not getting downloaded: Likely a firewall or network issue; investigate NSG, firewall, and VNET settings.
Nutshell Series

The environment block used to start a process can not be longer than 65535 bytes” in Azure Logic Apps

Manjunath

When working with Azure Logic Apps/ Function Apps/ App Service, you might encounter the following error:

“The environment block used to start a process cannot be longer than 65535 bytes. Your environment block is 85754 bytes long. Remove some environment variables and try again.”

This happens because **Azure app settings** are stored as **environment variables**, and Windows enforces a strict 65,535-byte limit on the total size of these variables. If the combined size exceeds this limit, the process fails to start.

Why Does This Happen?

In Azure Logic Apps, this issue typically arises due to:

  • Too many app settings defined in the configuration.
  • Very large values stored in app settings.
  • App settings with Azure Key Vault references, where the **size of the actual secret value** also contributes to the total environment block size.
  • Dependencies (e.g., SDKs, connectors) adding long **environment variables** automatically.

Even though Key Vault references are intended to keep secrets secure, the **retrieved secret value** is still counted towards the **app setting size**, potentially leading to this issue.

How to Fix It

1. Identify Large App Settings

To check the total size of app settings in Azure:

  • Go to the Azure Portal.
  • Navigate to your Logic App → Configuration.
  • Review the app settings listed under the Application settings tab.

If you are using Key Vault references, be aware that the actual **size of the secret value** is included in the environment block.

2. Remove or Reduce Unnecessary App Settings

  • Delete unused app settings that are no longer required.
  • Shorten long values, especially for connection strings, JSON configurations, or large text-based settings.
  • Avoid storing large secrets in Key Vault if they are referenced in app settings, as their size still counts towards the limit.

3. Store Large Data in External Services

  • Use Azure Key Vault with direct API calls instead of app setting references. This prevents secrets from being loaded as environment variables.
  • Use Azure App Configuration for managing configurations separately from app settings.
  • Store large JSON configurations or data-heavy settings in Azure Blob Storage or Cosmos DB.

4. Restart the Logic App

After making changes, restart your Logic App for the new settings to take effect.

Azure, Azure Integration Services, Nutshell Series

Understanding DNAT, Application, and Network Rules in Azure Firewall

Manjunath

Azure Firewall is a cloud-native security service that provides advanced threat protection for Azure workloads. It supports three main rule types:

  • DNAT (Destination Network Address Translation) Rules – Used to expose internal resources externally.
  • Application Rules – Controls outbound HTTP(S) traffic using FQDNs, URL filtering, and web categories.
  • Network Rules – Filters non-HTTP(S) traffic based on IP addresses, ports, and service tags.

1. DNAT (Destination Network Address Translation) Rules

DNAT rules allow inbound traffic from the internet. This traffic can be redirected to a private resource inside an Azure Virtual Network (VNet).

Example DNAT Rule

Source Type/IP/IP GroupDestination IP/PortTranslated IP/FQDNTranslated PortProtocol
52.10.20.3044310.1.0.10 or app.internal.local443TCP or UDP

2. Application Rules

Application rules control outbound HTTP(S) traffic using:

  • FQDNs (e.g., *.microsoft.com)
  • FQDN Tags (e.g., WindowsUpdate, AzureActiveDirectory)
  • URL Filtering (block specific URLs)
  • Web Categories (e.g., Social Networking, Streaming)

Example Application Rule

Source IP RangeProtocolPortAllowed FQDNsFQDN TagWeb Category
10.0.0.0/24HTTPS443*.microsoft.comWindowsUpdateShopping

3. Network Rules

Network rules filter non-HTTP(S) traffic using:

  • IP Addresses
  • Service Tags (e.g., AzureSQL, Storage)
  • IP Groups
  • FQDNs

Example Network Rule

Source IP RangeDestination IP/FQDNProtocolPortService Tag
10.1.0.0/2410.2.0.10 or db.internal.localTCP1433 (SQL)AzureSQL

4. Comparison of DNAT, Application, and Network Rules

Destination Types

Rule TypeBest ForFilters BySupports FQDN?Supports FQDN Tags?Supports URL Filtering?Supports Web Categories?Supports Service Tags?Supports IP Groups?Supports IP Addresses?
DNAT RulesInbound traffic redirectionFirewall IP → Translated IP/FQDN✅❌❌❌❌❌✅ (Destination)
Application RulesOutbound HTTP(S) controlFQDNs, FQDN Tags, URLs, Web Categories✅✅✅✅❌❌❌
Network RulesNon-HTTP traffic controlIP, Service Tags, FQDN, IP Groups✅❌❌❌✅✅✅

5. When to Use Each Rule Type

  • DNAT Rules – Expose internal resources to external users.
  • Application Rules – Control outbound HTTP(S) traffic with FQDN, URL filtering, and Web Categories.
  • Network Rules – Allow or block non-HTTP(S) traffic based on IPs, Service Tags, and IP Groups.
Security

How to Remove the AEAD Flag in GPG and Verify Changes

Manjunath

GPG (GNU Privacy Guard) is a powerful encryption tool that provides secure communication and file encryption. If you want to remove the AEAD (Authenticated Encryption with Associated Data) flag from your GPG key preferences, follow the steps below. We will also include commands to save your changes and verify the updated preferences.

Step 1: Access Key Preferences

To begin, you need to edit the specific GPG keys where you want to update the preferences.

Use the following command to open the key in expert editing mode:

gpg --expert --edit-key <key_id>

Replace <key_id> with the actual key ID of your GPG key. For example:

gpg --expert --edit-key ******************************

Step 2: View Current Preferences

Once inside the GPG key editing interface, you can view the current preferences by typing:

showpref

This will display the algorithms and preferences currently set for the key. Review them to confirm the presence of the AEAD flag or any settings you want to change.

Step 3: Update Key Preferences

To update the preferences and remove the AEAD flag, use the setpref command with your desired configuration. For example:

setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP

This command updates the preferences to include specific encryption algorithms, hashing algorithms, and compression methods. Ensure you list only the options you wish to use.

Step 4: Save Changes

After updating the preferences, save the changes by typing:

save

This will exit the key editing interface and apply the updates to the GPG key.

Step 5: Verify Changes

To verify that the preferences have been updated correctly, use the following command to list your keys:

gpg --list-keys

Locate the relevant key in the output and confirm that the preferences match your updated configuration. You can also re-enter the key editing interface and use the showpref command to confirm:

gpg --expert --edit-key <key_id>
showpref

This ensures that the AEAD flag has been successfully removed and your desired preferences are in place.

Conclusion

By following these steps, you can effectively remove the AEAD flag from your GPG key preferences and verify that the changes have been applied. Properly managing your encryption settings ensures that your communications and data remain secure and compatible with your requirements.

AI, ML, Security

The Rise of AI Operating Systems and Machine Learning: A Look at Responsible AI and Security

Manjunath

Artificial Intelligence (AI) and Machine Learning (ML) are reshaping how we interact with technology. As AI models grow more sophisticated, there is an increasing interest in AI operating systems (AI OS)—a new breed of platforms designed to manage and optimize AI resources efficiently. With the proliferation of AI-driven applications, the importance of responsible AI and security has also come to the forefront. In this blog, we’ll dive into AI OS, the role of ML, and the critical concepts of responsible AI and security.

Understanding AI Operating Systems

An AI Operating System is a specialized software platform that facilitates the efficient execution, management, and optimization of AI workloads. Unlike traditional operating systems designed to manage conventional computing resources, AI OS caters specifically to the unique needs of AI models, such as rapid training, real-time inferencing, and dynamic data handling.

Some key components of an AI OS include:

  • Resource Optimization: AI OS efficiently allocates CPU, GPU, and memory resources, ensuring smooth execution of AI algorithms while minimizing latency.
  • ML Model Management: AI OS platforms typically come with built-in tools for managing machine learning models, from deployment to monitoring and updates.
  • Scalability: Scalability is crucial, and AI OS can adapt to handle vast amounts of data as AI-driven applications evolve.
  • Interoperability: AI OS often comes with support for multiple AI frameworks such as TensorFlow, PyTorch, and ONNX, allowing developers the flexibility to choose their preferred tools.

AI OS solutions, like Microsoft Azure AI, Google’s Vertex AI, and NVIDIA’s AI Enterprise, are leading the way by providing platforms that cater to both developers and businesses aiming to streamline their AI projects.

Machine Learning: A Core Pillar of AI OS

Machine Learning forms the backbone of any AI OS. ML algorithms help automate processes, derive insights, and make decisions without human intervention. In an AI OS, machine learning can be leveraged in several ways:

  • Data Processing and Analysis: ML models process and analyze large datasets in real-time, providing the necessary insights for making informed decisions.
  • Model Training and Optimization: AI OS automates model training, optimizing hyperparameters, and ensuring efficient use of resources.
  • Personalization: AI OS platforms use ML to personalize user interactions based on preferences and behaviors, creating a better user experience.

The Importance of Responsible AI

While AI has the potential to transform industries, it also comes with challenges that must be addressed to ensure its responsible use. Responsible AI is a framework for ensuring that AI technologies are developed and used in ways that are fair, ethical, and safe.

Key principles of responsible AI include:

  • Fairness: AI systems should be free from bias and discrimination. It’s essential to ensure that the data used to train AI models is representative and does not introduce biases that could result in unfair outcomes.
  • Transparency: AI models should be transparent and explainable. Users should have the ability to understand how an AI system makes its decisions, especially in high-stakes scenarios like finance, healthcare, or law.
  • Accountability: Organizations should be accountable for the outcomes of their AI models. Clear lines of responsibility must be drawn to ensure any errors or harms can be addressed appropriately.
  • Privacy: AI OS should handle data in a way that respects user privacy, complying with regulations such as GDPR. Data anonymization and secure storage are critical elements of responsible AI.

Security in AI OS and ML

With the rise of AI-driven technologies, securing AI systems has become increasingly important. AI OS and ML models can be vulnerable to several types of attacks, including:

  • Data Poisoning: Data poisoning occurs when attackers introduce malicious data into the training set, leading the model to produce incorrect predictions. Ensuring the integrity of training datasets is critical to prevent such attacks.
  • Model Inversion Attacks: In model inversion attacks, adversaries can reconstruct sensitive information from a model’s predictions. To mitigate this, AI OS platforms should employ techniques like differential privacy to safeguard user data.
  • Adversarial Attacks: These are attempts to manipulate input data in a way that misleads the model into making incorrect decisions. Using robust ML techniques and adversarial training can help make models more resilient.
  • Access Control and Authentication: AI OS must ensure that access to sensitive data and models is restricted to authorized personnel only. Strong authentication and role-based access control (RBAC) mechanisms are key to ensuring security.

A secure AI environment also involves continuous monitoring, regular security audits, and updating ML models as new vulnerabilities are discovered.

The Future of AI OS: Balancing Innovation, Responsibility, and Security

AI Operating Systems are opening new doors for innovation, making AI more accessible and efficient. The future of AI OS will likely involve deeper integrations between machine learning models and AI-driven applications, helping businesses optimize their workflows and make data-driven decisions faster.

However, as AI technology becomes more pervasive, the need for responsible AI and stringent security protocols will continue to grow. Developers, organizations, and governments must work together to establish frameworks, guidelines, and best practices that ensure AI benefits everyone while minimizing its risks.

AI OS and machine learning represent the cutting edge of technology. By emphasizing responsible AI and security, we can ensure that these advancements contribute positively to society and are adopted in ways that are ethical, safe, and beneficial to all.

Nutshell Series

How to Convert an SSH-RSA Key to SSH2 Format

Manjunath

Secure Shell (SSH) keys are vital for maintaining secure communications between servers and clients. Most SSH users are familiar with the SSH-RSA key format, but in some cases, you may encounter a situation where you need to convert your key to SSH2 format. In this blog post, I’ll guide you through the process of converting your SSH-RSA key to SSH2 format using common tools like ssh-keygen and PuTTYgen.

Understanding SSH-RSA and SSH2

Before we dive into the technical details, let’s quickly cover what these formats represent:

SSH-RSA: This is a widely used format for SSH public keys. It starts with ssh-rsa and is often followed by a base64-encoded string and an optional comment (usually the username and hostname).

SSH2: This format is typically used by certain SSH clients and servers that adhere to the SSH2 protocol specification (RFC 4716). While SSH2 itself is the protocol, some clients require a specific key format associated with it.


In most cases, the key types are the same; it’s the formatting that may differ slightly based on the SSH client or server you’re using.

Why Convert SSH-RSA to SSH2?

You may need to convert your SSH-RSA key to SSH2 format when working with specific clients, such as older SSH tools or certain security appliances, which require SSH2 format.

Converting SSH-RSA to SSH2 Format Using ssh-keygen

The simplest way to convert an SSH-RSA public key to SSH2 format is by using the ssh-keygen tool. Here’s how you can do it:

Step 1: Open Your Terminal

If you are using Linux or macOS, open your terminal. On Windows, you can use a tool like Git Bash or Windows Subsystem for Linux (WSL) to access the terminal.

Step 2: Run the ssh-keygen Command

Assuming you have the SSH-RSA public key file (id_rsa.pub), you can convert it using this command:

ssh-keygen -f id_rsa.pub -e -m RFC4716 > id_rsa_ssh2.pub

Let’s break this command down:

-f id_rsa.pub: Specifies the file you want to convert (your SSH-RSA public key).

-e: Indicates that you want to export the key.

-m RFC4716: This flag converts the key to SSH2 format (RFC 4716).

> id_rsa_ssh2.pub: Saves the converted key to a new file.


The result will be an SSH2-compatible public key, which looks like this:

—- BEGIN SSH2 PUBLIC KEY —-
Comment: “2048-bit RSA, user@example.com”
AAAAB3NzaC1yc2EAAAABIwAAAQEAr0…
—- END SSH2 PUBLIC KEY —-

Converting SSH-RSA to SSH2 Using PuTTYgen (Windows)

If you are a Windows user, you can convert SSH keys using PuTTYgen, which is part of the PuTTY suite. Here’s how:

Step 1: Open PuTTYgen

Download and install PuTTYgen from the PuTTY official website if you haven’t already. Then, open the application.

Step 2: Load Your SSH-RSA Key

Click on Load.

Navigate to where your SSH-RSA public key file is located, and load it into PuTTYgen.


Step 3: Save the SSH2 Public Key

Once your key is loaded, click Save public key.

This will export your key in an SSH2-compatible format.


Verifying Your SSH2 Key

Once you’ve converted your key, it’s a good idea to verify that it works as expected with your SSH client or server. You can do this by copying the new SSH2 key to the appropriate location (such as ~/.ssh/authorized_keys on a remote server) and testing the connection.

Conclusion

Converting an SSH-RSA key to SSH2 format is straightforward, especially with tools like ssh-keygen or PuTTYgen. Whether you’re switching to a new SSH client or meeting a specific protocol requirement, these steps will help you get your keys in the right format.

Nutshell Series

How to Generate a PGP Key Pair on Windows

Manjunath

Generating a PGP key pair on Windows is straightforward using either the command line or Kleopatra. Follow these concise steps to get started.

Method 1: Using GPG Command Line

  • Step 1: Install Gpg4win/ Git cli
  • Step 2: Open Command Prompt/ Git cli.
  • Step 3: Run gpg --full-generate-key.
  • Step 4: Choose:
    • 1 for RSA and RSA.
    • 4096 for key size.
    • Expiration: set or choose 0 for none.
  • Step 5: Enter your name and email.
  • Step 6: Set a passphrase.
  • Step 7: Export keys:
    • Public key: gpg --armor --export your_email@example.com > publickey.asc
    • Private key: gpg --armor --export-secret-keys your_email@example.com > privatekey.asc

Method 2: Using Kleopatra

  • Step 1: Install Gpg4win (includes Kleopatra).
  • Step 2: Open Kleopatra.
  • Step 3: Click New Key Pair.
  • Step 4: Enter your name and email.
  • Step 5: Set a passphrase.
  • Step 6: Export keys:
    • Public key: Right-click, Export.
    • Private key: Right-click, Export Secret Keys.

Following these steps, you’ll have your PGP key pair ready for encrypting and signing data on Windows!

Azure, Azure Integration Services, Nutshell Series

Azure Tagging Strategies

Manjunath

Tags in Azure help organize resources for cost management, governance, and automation. Here’s a quick guide to effective tagging.

Common Tag Categories

  • Owner: Who is responsible for the resource (e.g., Owner).
  • Billing: Track costs (e.g., CostCenter, Project).
  • Environment: Classify resources by environment (e.g., Production, Development).
  • Application: Identify apps or services (e.g., Application, Role).
  • Compliance: Ensure security and compliance (e.g., Compliance, DataClassification).

Best Practices

  • Use consistent tag keys and values.
  • Inherit tags to all resources from resource groups.
  • Limit tags to essentials for simplicity.
  • Automate tagging using Azure Policy and CLI.
  • Leverage tags for cost tracking and governance.

“Tags are vital for managing cloud resources efficiently in Azure.”

– Azure Expert
Learn More About Azure Tags