33 C
Dubai
Tuesday, April 29, 2025
Home Blog Page 4

Exploring Azure SQL Database Auto-Failover Group for Seamless Disaster Recovery

Santhosh M
-
0
Exploring Azure SQL Database Auto-Failover Group for Seamless Disaster Recovery

Azure SQL Database Auto-Failover Group is a feature designed to enhance the availability and resilience of databases in Azure SQL Database. It enables automatic failover of a group of databases from a primary server to a secondary server in the event of a planned or unplanned outage, ensuring minimal downtime and data loss. This feature provides high availability and disaster recovery capabilities by synchronously replicating databases between primary and secondary servers within the same region or across different regions.

Advantages:

  1. Continuous data synchronization: Ensures that data changes are replicated in real-time between primary and secondary servers, minimizing the risk of data loss.
  2. Automatic failover with minimal downtime: Enables automatic failover to the secondary server in the event of a primary server failure, ensuring business continuity with minimal disruption to operations.
  3. Support for manual failover: Allows administrators to initiate manual failover for planned maintenance or testing purposes, providing flexibility and control over the failover process.
  4. Simplified management: Offers an intuitive interface through the Azure portal or PowerShell commands for easy configuration, monitoring, and management of failover groups.
  5. Regional and cross-regional replication: Supports replication between primary and secondary servers within the same region or across different regions, enabling robust disaster recovery strategies for geographically distributed applications.

Step 1: Begin by setting up an Azure SQL database and server. This is the foundation for testing the Auto-Failover Group for Disaster Recovery. In Azure, you can easily create these resources through the Azure Portal or by using Azure CLI commands. Ensure that you choose appropriate configurations and settings to match your testing requirements.

Check the configurations and click on create.

Step 2: Navigate to the networking section of your Azure SQL Primary server configuration. Here, you’ll want to add your public IP address to allow access to the server. By doing this, you ensure that your IP is authorized to interact with the SQL server.

Step 3: Within the primary server’s Data Management settings, locate and click on “Failover Groups.” Then, proceed to click on “Add Group.” This action initiates the setup process for creating a Failover Group.

Step 4: Assign a descriptive name to your Failover Group. This identifier will serve as a common server ID for accessing all servers associated with this Failover Group. Choosing a clear and intuitive name will streamline management and facilitate navigation within your Azure environment

Step 5: Proceed to create a Secondary server, ensuring it’s located in a distinct geographical location from the primary server. This geographical diversity is crucial for robust disaster recovery planning. By syncing the Secondary server with the primary, you establish a failover mechanism, ensuring data accessibility even in the event of Primary server failure.

Select the required databases that need to be synced with the Secondary Server.

Step 6: Utilize Azure SQL Management Studio to establish a local connection to the database. When prompted for connection details, input the Failover Group ID to seamlessly access the database resources.

Provide the Login Credentials and connect to the SQL Server.

Step 7: Enhance your database management by adding queries to ascertain from which server the database is being accessed. This step aids in monitoring and troubleshooting, providing valuable insights into the source of database requests. Currently its connected to the Primary Server.

Step 8: Within the Failover Groups section, locate and select “Forced Failover” to simulate a server-level failure for the primary server. This action triggers the failover process, directing database operations to the secondary server as per the configured failover settings.

Following the forced failover, the secondary server assumes the role of the primary server, while the original primary server transitions to become the secondary server. This exchange ensures continuity of database operations, with the former secondary server now serving as the primary point of access for data retrieval and management.

Step 9: In the networking settings of the newly promoted primary server (formerly the secondary server), add your public IP address. This action mirrors the configuration performed earlier on the original primary server, ensuring that your IP remains authorized to interact with the server.

Step 10: Deploy queries within your database environment to ascertain the source of data retrieval requests. Specifically, craft queries to confirm that data access originates from the newly promoted primary server, which was formerly the secondary server. This verification step confirms the successful failover process, demonstrating that database operations are now being conducted from the secondary server, which has assumed the role of the primary server following the failover event.

.

Disable Changing Picture in Teams

Satheshwaran Manoharan
-
0
Disable Changing Picture in Teams

Install Exchange Online Management Module

If you set SetPhotoEnabled to False in OWA Mailbox Policy. Microsoft teams will honor it.
if you have a hybrid server, make sure you run on Exchange On-Premises and Office 365 PowerShell (Connect-ExchangeOnline)
For changing this setting for a specific set of users you need to create a dedicated OWA Mailbox policy.

Get-OwaMailboxPolicy | FL identity,Setphotoenabled 
Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -SetPhotoEnabled $false

Now when you try to change the picture in Teams
Picture Options are disabled by policy.

Disk Encryption BitLocker Policy in Intune Endpoint Security

Satheshwaran Manoharan
-
0
Disk Encryption BitLocker Policy in Intune Endpoint Security

Note: BitLocker Policy configurations are not applicable for the devices that enrolls through Autopilot Enrollment. As the new devices gets encrypted automatically.

BitLocker automatically encrypts internal drives during the out of box experience (OOBE) for devices that support Modern Standby or meet the Hardware Security Testability Specification (HSTI). By default, BitLocker uses XTS-AES 128-bit used space only for automatic encryption.

  • Autopilot Enrollment method for enrolling devices to Microsoft Intune has its own automatic encryption without a BitLocker Policy
  • By default, XTS-AES 128-bit (default) BitLocker configuration is applied to Autopilot Enrolled device.
  • BitLocker policy can be used for Hybrid Joined Devices. (Devices which are applied via SCCM should not have any impact on this)

M365 Disk Encryption Profile to deploy BitLocker using Intune for your laptops and desktops, Microsoft Made it seamless to deploy them.

Note: We recommend going on with 128 bits as Autopilot is encrypting 128 bits by default.

If you go with 128 bits. if you have Auto Pilot Devices it’s going to be automatically encrypted and if you have a 128-bit BitLocker policy applied on top of 128 bit. it’s going to apply seamlessly, and no changes will be made., So that you can keep 128 bits across the environment.

If you go with 256 bits. if you have Auto Pilot Devices it’s going to be automatically encrypted and if you have a 256-bit BitLocker policy applied on top of 128 bit. it’s not going to apply seamlessly, and the device needs to be decrypted to encrypt again, Either Manual or You need to apply a custom registry to disable default encryption so that you can keep 256 bits across the environment.

Hence, we recommend 128 bits, so that everything goes smooth on an Auto Pilot Environment even without a bit locker Policy.

.
.

We are recommending 128 bit – Not 256 bit.

BitLocker Silent Deploy

Encrypt Windows devices with BitLocker in Intune – Microsoft Intune | Microsoft Docs

Known Errors –
Start – Eventvwr – Application and Service Logs – Microsoft – Windows – Bitlocker-API – Management

It Failed to enable Silent Encryption.

Error: Group policy prevents you from backing up your recovery password to Active Directory for this drive type. For more info, contact your system administrator.

Solution – Policy Misconfigured – Require device to backup recovery information to Azure AD is not Configured – It should be configured to resolve it.


Error: BitLocker cannot use Secure Boot for integrity because it is disabled.

manage-bde -protectors -get c:

This shows that PCR 7 is NOT in use / Even though the secure boot is enabled.


Solution – 

manage-bde -protectors c: -delete -t tpm
manage-bde -protectors c: -add -tpm

Error 1: BitLocker could not be enabled

The Bitlocker encryption key cannot be obtained. Verify that the Trusted Platform Module (TPM) is enabled and ownership has been taken.if this computer does not have TPM, verify that the USB drive is inserted and available.

C: was not encrypted

Error 2: BitLocker cannot use Secure Boot for integrity because the UEFI variable ‘SecureBoot’ could not be read.

Solution for #1 and #2: Clear the TPM using TPM.msc

Deploying Docker Image to Azure Container Registry and Hosting it with Azure Web App Service.

Santhosh M
-
0
Deploying Docker Image to Azure Container Registry and Hosting it with Azure Web App Service.

Step 1: Establish an Azure Container Registry (ACR) as a central repository to store and manage your Dockerized application images efficiently and securely.

Check the Configurations and click on create.

.

In Azure Container Registry fill the checkbox Admin Users and save it.

Step 2: Begin by creating an App Service in Azure, specifying a name for the Web App, choosing Docker Container as the hosting option, and selecting your preferred location for deployment. This sets up the infrastructure required to host your Dockerized application on Azure Web App Service.

Check the configurations and Click on create.

Step 3: Use the ‘az login’ command to authenticate and log in to your Azure subscription, granting access to manage Azure resources such as Azure Container Registry (ACR) and Azure Web App.


Step 4: Authenticate with your Azure Container Registry (ACR) using the ‘az acr login’ command followed by the name of your ACR instance, ensuring access to push and pull Docker images to and from the registry.

az acr login --name acrname

Step 5: Build your image using the Docker Build command.

docker build -t docker-image-name .

Step 6: Add a tag to the Docker image.

docker tag image_name acr-name.azurecr.io/image_name:latest

Step 7: Execute the ‘docker push’ command, specifying the tag of your local Docker image and the fully qualified name of your Azure Container Registry (ACR), to upload the image from your local repository to the ACR, making it available for deployment to Azure services like Azure Web App.

docker push acr-name.azurecr.io/image-name:latest

Step 8: Access the Web App and proceed to the Deployment Center. Choose Docker Compose as the deployment option, then select Azure Container Registry. Pick the appropriate Azure Container Registry and configure the port as 80. Enable Continuous Deployment to automate the deployment process.

  • Select Docker Compose
  • Select Azure Container Registry
  • Select the Required Azure Container Registry
  • In Config Provide Port 80
  • Set Continuous Deployment – On

Step 9: Verify the hosting of your Docker image by accessing your Azure Web App URL in a web browser to view the app’s details, confirming successful deployment and hosting of the image on Azure Web App.

Use Winget to deploy apps on Intune.

Dinesh D P
-
1
Use Winget to deploy apps on Intune.

The fast and best way to package & deploy applications in Intune,

No need to update the application often for new versions, Limit your application size & save time in application upload.

Winget documentation reference https://learn.microsoft.com/en-us/windows/package-manager/winget/

The winget command line tool enables users to discover, install, upgrade, remove and configure applications on Windows 10 and Windows 11 computers. This tool is the client interface to the Windows Package Manager service.

Note: The winget command line tool is only supported on Windows 10 1709 (build 16299) or later. The scrips on this document are reusable by changing the application ID.

Finding Application ID

Use winget search followed by the application name to find the application ID. In this example, Finding the Application ID for Pycharm.

Open powershell as an administrator

winget search pycharm

Create installation script.

Create a PowerShell file and add this command.

Note: Not all installers support installing in “user” scope and “machine” scope consistently.  “–scope=user” refers to the application installation directory, path C:\Users\JohnS\AppData\Roaming\JetBrains\PyCharm2023.3.  

winget install -e --id JetBrains.PyCharm.Community --silent --accept-package-agreements --accept-source-agreements

Create uninstallation script.

Create a PowerShell file and add this command.

winget.exe uninstall -e --id JetBrains.PyCharm.Community --silent --accept-source-agreements

Detection script.

Create a PowerShell script and add the below script.

##What is the latest version Pycharm
$JBNSearch = winget.exe search -e --id JetBrains.PyCharm.Community --accept-source-agreements
$JBNOnlineVersion = (-split $JBNSearch[-1])[-2]

##What is the version installed
$JBNLocalSearch = winget.exe list -e --id JetBrains.PyCharm.Community
$JBNCheckIfAvailavbleExist = (-split $JBNLocalSearch[-3])[-2]
if($JBNCheckIfAvailavbleExist -eq "Available")
{
    $JBNLocalVersion = (-split $JBNLocalSearch[-1])[-3]
}
else
{
    $JBNLocalVersion = (-split $JBNLocalSearch[-1])[-2]
}
if($JBNLocalVersion -eq "input")
{
    exit 1
 #Detection failed
}
if($JBNLocalVersion -ge $JBNOnlineVersion)
{
    Write-Output "The Device got the latest version of Postman installed"
 exit 0
 #Detection success
}
else
{
 exit 1
 #Detection failed
}

Download Microsoft Win32 Content.

Web url: https://learn.microsoft.com/en-us/mem/intune/apps/apps-win32-prepare

Download url: https://github.com/Microsoft/Microsoft-Win32-Content-Prep-Tool

Package the PowerShell script.

Open IntuneWinAppUtil.exe as an administrator.

Enter source directory.

Specify installation file name.

Specify output folder path.

Package Created

Application deployment in Intune.

Installation & Uninstallation command.

Only change the ps1 file name

Installation Command

powershell.exe -WindowStyle hidden -ExecutionPolicy ByPass -File .\Pycharminstallation.ps1

Uninstall Command

powershell.exe -WindowStyle hidden -ExecutionPolicy ByPass -File .\Pycharmuninstallation.ps1

Review and Create

Install the application form the Company Portal

Enhancing Email Security: Tagging External Emails in Microsoft 365

Santhosh M
-
0
Enhancing Email Security: Tagging External Emails in Microsoft 365

Adding tags to external emails in Microsoft 365 is a security measure aimed at enhancing email security by visually identifying emails originating from external sources. These tags can help users quickly identify emails that are coming from outside the organization, which may potentially be more susceptible to phishing attacks, spoofing, or other malicious activities.

By adding tags to external emails, organizations can:

  1. Improve Awareness: Users can easily identify emails originating from external sources, helping them exercise caution and be more vigilant when interacting with such emails.
  2. Enhance Security: The visual cue provided by the tag serves as an additional layer of security, helping users differentiate between internal and external emails and reducing the risk of falling victim to phishing or other email-based threats.
  3. Reduce Risk: With clear visual indicators for external emails, users are less likely to inadvertently click on suspicious links or download malicious attachments, thereby reducing the risk of security breaches.

Step 1:Open PowerShell as Administrator and install the ExchangeOnlineManagement module using ‘Install-Module -Name ExchangeOnlineManagement’ command.

Install-Module -Name ExchangeOnlineManagement

Step 2:After installing the ExchangeOnlineManagement module, you need to establish a connection to it using the “Connect-ExchangeOnline” cmdlet, which prompts for credentials to authenticate your session.

Connect-ExchangeOnline

Step 3: Utilize the command “Get-ExternalInOutlook | Format-Table” in PowerShell to retrieve external contacts from Outlook and format the output into a table for convenient viewing.

Get-ExternalInOutlook | Format-Table

Step 4: Execute the command “Set-ExternalInOutlook -Enabled $true” in PowerShell to enable the addition of an external tag to emails sent from external sources. This tag enhances identification and management of external communications within the Outlook environment.

Set-ExternalInOutlook -Enabled $true

Now if we view the table the value will be set to be True.

Step 5: After setting the value to “true” using “Set-ExternalInOutlook -Enabled $true” in PowerShell, emails originating from external sources will be automatically labeled with an “external” tag. This aids in distinguishing external emails for improved organization and security management within the Outlook system.

Step 6: Exclude specific external IDs from being marked as external by executing the command “Set-ExternalInOutlook -AllowList @{Add=’contoso.com’, ‘microsoft.com’}” in PowerShell. This command adds domains like “contoso.com” and “microsoft.com” to the allow list, ensuring that emails from these domains are not tagged as external, thereby enhancing email management flexibility and classification.

Set-ExternalInOutlook -AllowList @{Add="abcd.com", "microsoft.com"}

Check the table the external domains will be added.

Step 7: After adding a domain to the allow list using “Set-ExternalInOutlook -AllowList @{Add=’domain.com’}” in PowerShell, emails originating from that domain will not receive an external tag. This ensures that messages from the specified domain are exempt from being labeled as external, streamlining email management and enhancing organizational efficiency.

Step 8:Remove domains from the allow list by executing the command “Set-ExternalInOutlook -AllowList @{Remove=’abcd.com’, ‘microsoft.com’}” in PowerShell. This command removes domains such as “contoso.com” and “microsoft.com” from the allow list, allowing external tags to be applied to emails from these domains as usual.

Set-ExternalInOutlook -AllowList @{Remove="abcd.com", "microsoft.com"}

Step 9: After removing external domains from the allow list, verify the changes by checking the table in PowerShell. This ensures that emails from previously allowed domains will now receive external tags, aiding in effective email management and classification.

1...345...113Page 4 of 113

EDITOR PICKS

POPULAR POSTS

POPULAR CATEGORY

ABOUT ME

Satheshwaran Manoharan - Microsoft MVP - Award-winning Technology Leader with a wealth of experience running large teams and diversified industry exposure in cloud computing. From shipping lines to rolling stocks.In-depth expertise in driving cloud adoption strategies and modernizing systems to cloud native. Specialized in Microsoft Cloud, DevOps, and Microsoft 365 Stack and conducted numerous successful projects worldwide. Also, Acting as a Technical Advisor for various start-ups.

Contact : Info@Azure365Pro.com

FOLLOW US

© Azure365Pro.com

× How can I help you?