Merge pull request #256948 from MicrosoftDocs/main

11/1/2023 AM Publish

Author: Taojunshen

articles/api-management/developer-portal-extend-custom-functionality.md

@@ -117,7 +117,11 @@ For more advanced use cases, you can create and upload a custom widget to the de
     npm run deploy
     ```
 
-    If prompted, sign in to your Azure account. 
+    If prompted, sign in to your Azure account.
+
+   > [!NOTE]
+   > When prompted to sign in, you must use a member account from the Microsoft Entra ID tenant that's associated with the Azure subscription where your API Management service resides. The account must not be a guest or a federated account and must have the appropriate permission to access the portal's administrative interface. 
+
 
 The custom widget is now deployed to your developer portal. Using the portal's administrative interface, you can add it on pages in the developer portal and set values for any custom properties configured in the widget.
 

articles/azure-monitor/agents/azure-monitor-agent-troubleshoot-linux-vm-rsyslog.md

@@ -13,8 +13,10 @@ ms.reviewer: shseth
 Overview of Azure Monitor Agent for Linux Syslog collection and supported RFC standards:
 
 - Azure Monitor Agent installs an output configuration for the system Syslog daemon during the installation process. The configuration file specifies the way events flow between the Syslog daemon and Azure Monitor Agent.
-- For `rsyslog` (most Linux distributions), the configuration file is `/etc/rsyslog.d/10-azuremonitoragent.conf`. For `syslog-ng`, the configuration file is `/etc/syslog-ng/conf.d/azuremonitoragent.conf`.
-- Azure Monitor Agent listens to a UNIX domain socket to receive events from `rsyslog` / `syslog-ng`. The socket path for this communication is `/run/azuremonitoragent/default_syslog.socket`.
+- For `rsyslog` (most Linux distributions), the configuration file is `/etc/rsyslog.d/10-azuremonitoragent-omfwd.conf`. For `syslog-ng`, the configuration file is `/etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf`.
+- Azure Monitor Agent listens to a TCP port to receive events from `rsyslog` / `syslog-ng`. The port for this communication is logged at `/etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port`.
+  > [!NOTE]
+  > Before Azure Monitor Agent version 1.28, it used a Unix domain socket instead of TCP port to receive events from rsyslog. `omfwd` output module in `rsyslog` offers spooling and retry mechanisms for improved reliability.
 - The Syslog daemon uses queues when Azure Monitor Agent ingestion is delayed or when Azure Monitor Agent isn't reachable.
 - Azure Monitor Agent ingests Syslog events via the previously mentioned socket and filters them based on facility or severity combination from data collection rule (DCR) configuration in `/etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/`. Any `facility` or `severity` not present in the DCR is dropped.
 - Azure Monitor Agent attempts to parse events in accordance with **RFC3164** and **RFC5424**. It also knows how to parse the message formats listed on [this website](./azure-monitor-agent-overview.md#data-sources-and-destinations).
@@ -85,10 +87,10 @@ rsyslogd 1484 syslog   14w   REG    8,1 3601566564     0 35280 /var/log/syslog (
 ### Rsyslog default configuration logs all facilities to /var/log/
 On some popular distros (for example, Ubuntu 18.04 LTS), rsyslog ships with a default configuration file (`/etc/rsyslog.d/50-default.conf`), which logs events from nearly all facilities to disk at `/var/log/syslog`. RedHat/CentOS family Syslog events are stored under `/var/log/` but in a different file:  `/var/log/messages`.
 
-Azure Monitor Agent doesn't rely on Syslog events being logged to `/var/log/`. Instead, it configures the rsyslog service to forward events over a socket directly to the `azuremonitoragent` service process (mdsd).
+Azure Monitor Agent doesn't rely on Syslog events being logged to `/var/log/`. Instead, it configures the rsyslog service to forward events over a TCP port directly to the `azuremonitoragent` service process (mdsd).
 
 #### Fix: Remove high-volume facilities from /etc/rsyslog.d/50-default.conf
-If you're sending a high log volume through rsyslog and your system is set up to log events for these facilities, consider modifying the default rsyslog config to avoid logging and storing them under `/var/log/`. The events for this facility would still be forwarded to Azure Monitor Agent because rsyslog uses a different configuration for forwarding placed in `/etc/rsyslog.d/10-azuremonitoragent.conf`.
+If you're sending a high log volume through rsyslog and your system is set up to log events for these facilities, consider modifying the default rsyslog config to avoid logging and storing them under `/var/log/`. The events for this facility would still be forwarded to Azure Monitor Agent because rsyslog uses a different configuration for forwarding placed in `/etc/rsyslog.d/10-azuremonitoragent-omfwd.conf`.
 
 1. For example, to remove `local4` events from being logged at `/var/log/syslog` or `/var/log/messages`, change this line in `/etc/rsyslog.d/50-default.conf` from this snippet:
 

articles/azure-monitor/agents/data-collection-syslog.md

@@ -104,59 +104,64 @@ If your VM doesn't have Azure Monitor Agent installed, the DCR deployment trigge
 When Azure Monitor Agent is installed on a Linux machine, it installs a default Syslog configuration file that defines the facility and severity of the messages that are collected if Syslog is enabled in a DCR. The configuration file is different depending on the Syslog daemon that the client has installed.
 
 ### Rsyslog
-On many Linux distributions, the rsyslogd daemon is responsible for consuming, storing, and routing log messages sent by using the Linux Syslog API. Azure Monitor Agent uses the UNIX domain socket output module (`omuxsock`) in rsyslog to forward log messages to Azure Monitor Agent.
+On many Linux distributions, the rsyslogd daemon is responsible for consuming, storing, and routing log messages sent by using the Linux Syslog API. Azure Monitor Agent uses the TCP forward output module (`omfwd`) in rsyslog to forward log messages to Azure Monitor Agent.
 
 The Azure Monitor Agent installation includes default config files that get placed under the following directory: `/etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/`
 
 When Syslog is added to a DCR, these configuration files are installed under the `etc/rsyslog.d` system directory and rsyslog is automatically restarted for the changes to take effect. These files are used by rsyslog to load the output module and forward the events to the Azure Monitor Agent daemon by using defined rules.
 
-The built-in `omuxsock` module can't be loaded more than once. For this reason, the configurations for loading of the module and forwarding of the events with corresponding forwarding format template are split in two different files. Its default contents are shown in the following example. This example collects Syslog messages sent from the local agent for all facilities with all log levels.
+Its default contents are shown in the following example. This example collects Syslog messages sent from the local agent for all facilities with all log levels.
 ```
-$ cat /etc/rsyslog.d/10-azuremonitoragent.conf
+$ cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
 # Azure Monitor Agent configuration: forward logs to azuremonitoragent
-$OMUxSockSocket /run/azuremonitoragent/default_syslog.socket
-template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%") 
-$OMUxSockDefaultTemplate AMA_RSYSLOG_TraditionalForwardFormat
-# Forwarding all events through Unix Domain Socket
-*.* :omuxsock: 
+
+template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%")
+# queue.workerThreads sets the maximum worker threads, it will scale back to 0 if there is no activity
+# Forwarding all events through TCP port
+*.* action(type="omfwd"
+template="AMA_RSYSLOG_TraditionalForwardFormat"
+queue.type="LinkedList"
+queue.filename="omfwd-azuremonitoragent"
+queue.maxFileSize="32m"
+action.resumeRetryCount="-1"
+action.resumeInterval="5"
+action.reportSuspension="on"
+action.reportSuspensionContinuation="on"
+queue.size="25000"
+queue.workerThreads="100"
+queue.dequeueBatchSize="2048"
+queue.saveonshutdown="on"
+target="127.0.0.1" Port="28330" Protocol="tcp")
 ```
 
-```
-$ cat /etc/rsyslog.d/05-azuremonitoragent-loadomuxsock.conf
-# Azure Monitor Agent configuration: load rsyslog forwarding module. 
-$ModLoad omuxsock
-```
-
 On some legacy systems, such as CentOS 7.3, we've seen rsyslog log formatting issues when a traditional forwarding format is used to send Syslog events to Azure Monitor Agent. For these systems, Azure Monitor Agent automatically places a legacy forwarder template instead:
 
 `template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n")`
 
 ### Syslog-ng
 
-The configuration file for syslog-ng is installed at `/etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent.conf`. When Syslog collection is added to a DCR, this configuration file is placed under the `/etc/syslog-ng/conf.d/azuremonitoragent.conf` system directory and syslog-ng is automatically restarted for the changes to take effect.
+The configuration file for syslog-ng is installed at `/etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf`. When Syslog collection is added to a DCR, this configuration file is placed under the `/etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf` system directory and syslog-ng is automatically restarted for the changes to take effect.
 
 The default contents are shown in the following example. This example collects Syslog messages sent from the local agent for all facilities and all severities.
 ```
-$ cat /etc/syslog-ng/conf.d/azuremonitoragent.conf 
-# Azure MDSD configuration: syslog forwarding config for mdsd agent options {}; 
-
-# during install time, we detect if s_src exist, if it does then we 
-
-# replace it by appropriate source name like in redhat 's_sys' 
-
-# Forwrding using unix domain socket 
-
-destination d_azure_mdsd { 
-
-unix-dgram("/run/azuremonitoragent/default_syslog.socket" 
-
-flags(no_multi_line) 
-
-); 
-}; 
-
-log {	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf 
-destination(d_azure_mdsd); }; 
+$ cat /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf 
+# Azure MDSD configuration: syslog forwarding config for mdsd agent
+options {};
+
+# during install time, we detect if s_src exist, if it does then we
+# replace it by appropriate source name like in redhat 's_sys'
+# Forwrding using tcp
+destination d_azure_mdsd {
+	network("127.0.0.1" 
+	port(28330)
+	log-fifo-size(25000));			
+};
+
+log {
+	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf
+	destination(d_azure_mdsd);
+	flags(flow-control);
+};
 ```
 
 >[!Note]

articles/azure-monitor/vm/vminsights-performance.md

@@ -26,6 +26,7 @@ Limitations in performance collection with VM insights:
 
 - Available memory isn't available in all Linux versions, including Red Hat Linux (RHEL) 6 and CentOS 6. It will be available in Linux versions that use [kernel version 3.14](http://www.man7.org/linux/man-pages/man1/free.1.html) or higher. It might be available in some kernel versions between 3.0 and 3.14.
 - Metrics are only available for data disks on Linux virtual machines that use XFS filesystem or EXT filesystem family (EXT2, EXT3, EXT4).
+- Collecting performance metrics from network shared drives is unsupported.
 
 ## Multi-VM perspective from Azure Monitor
 

articles/backup/azure-backup-architecture-for-sap-hana-backup.md

@@ -1,8 +1,8 @@
 ---
-title: Azure Backup Architecture for SAP HANA Backup
+title: Azure Backup architecture for SAP HANA Backup
 description: Learn about Azure Backup architecture for SAP HANA backup.
 ms.topic: conceptual
-ms.date: 06/20/2023
+ms.date: 11/02/2023
 ms.service: backup
 ms.custom: ignite-2022
 author: AbhishekMallick-MS
@@ -142,9 +142,27 @@ This section provides you with an understanding about the backup process of an H
 >[!Note]
 >For the HANA VMs that are already backed-up as individual machines, you can do the grouping only for future backups.  
 
+### Backup architecture for database instance snapshot
+
+Azure Backup integrates Azure-managed disk full or incremental snapshots with HANA snapshot commands to deliver instant backup and recovery capabilities for HANA.
+
+**SAP HANA database instance snapshot backup**
+
+The backup architecture explains the different permissions that are required for the Azure Backup service, which resides on a HANA virtual machine (VM), to take snapshots of the managed disks and place them in a user-specified resource group that's mentioned in the policy. To do so, you can use the system-assigned managed identity of the source VM.
+
+
+:::image type="content" source="./media/azure-backup-architecture-for-sap-hana-backup/sap-hana-database-instance-snapshot-backup-architecture.png" alt-text="Diagram shows the SAP HANA database instance snapshot backup architecture.":::
+
+**SAP HANA database instance snapshot restore**
+
+The restore architecture explains the different permissions required during the restore operation. Azure Backup uses the target VM’s managed identity to read disk snapshots from a user-specified resource group, create disks in a target resource group, and attach them to the target VM.
+
+:::image type="content" source="./media/azure-backup-architecture-for-sap-hana-backup/sap-hana-database-instance-snapshot-restore-architecture.png" alt-text="Diagram shows the SAP HANA database instance snapshot restore architecture.":::
+
+
 ## Next steps
 
 - Learn about the supported configurations and scenarios in the [SAP HANA backup support matrix](sap-hana-backup-support-matrix.md).
 - Learn about how to [backup SAP HANA databases in Azure VMs](backup-azure-sap-hana-database.md).
 - Learn about how to [backup SAP HANA System Replication databases in Azure VMs](sap-hana-database-with-hana-system-replication-backup.md).
-- Learn about how to [backup SAP HANA databases' snapshot instances in Azure VMs (preview)](sap-hana-database-instances-backup.md).
+- Learn about how to [backup SAP HANA databases' snapshot instances in Azure VMs](sap-hana-database-instances-backup.md).

articles/backup/backup-azure-sap-hana-database.md

@@ -2,7 +2,7 @@
 title: Back up an SAP HANA database to Azure with Azure Backup 
 description: In this article, learn how to back up an SAP HANA database to Azure virtual machines with the Azure Backup service.
 ms.topic: how-to
-ms.date: 05/24/2023
+ms.date: 11/02/2023
 ms.service: backup
 author: AbhishekMallick-MS
 ms.author: v-abhmallick
@@ -23,7 +23,7 @@ Refer to the [prerequisites](tutorial-backup-sap-hana-db.md#prerequisites) and t
 
 ### Establish network connectivity
 
-For all operations, an SAP HANA database running on an Azure VM requires connectivity to the Azure Backup service, Azure Storage, and Microsoft Entra ID. This can be achieved by using private endpoints or by allowing access to the required public IP addresses or FQDNs. Not allowing proper connectivity to the required Azure services may lead to failure in operations like database discovery, configuring backup, performing backups, and restoring data.
+For all operations, an SAP HANA database running on an Azure VM requires connectivity to the Azure Backup service, Azure Storage, and Microsoft Entra ID. This can be achieved by using private endpoints or by allowing access to the required public IP addresses or FQDNs. Not allowing proper connectivity to the required Azure services might lead to failure in operations like database discovery, configuring backup, performing backups, and restoring data.
 
 The following table lists the various alternatives you can use for establishing connectivity:
 
@@ -32,7 +32,7 @@ The following table lists the various alternatives you can use for establishing
 | Private endpoints                 | Allow backups over private IPs inside the virtual network  <br><br>   Provide granular control on the network and vault side | Incurs standard private endpoint [costs](https://azure.microsoft.com/pricing/details/private-link/) |
 | NSG service tags                  | Easier to manage as range changes are automatically merged   <br><br>   No additional costs | Can be used with NSGs only  <br><br>    Provides access to the entire service |
 | Azure Firewall FQDN tags          | Easier to manage since the required FQDNs are automatically managed | Can be used with Azure Firewall only                         |
-| Allow access to service FQDNs/IPs | No additional costs.   <br><br>  Works with all network security appliances and firewalls. <br><br> You can also use service endpoints for *Storage*. However, for *Azure Backup* and *Microsoft Entra ID*, you need to assign the access to the corresponding IPs/FQDNs. | A broad set of IPs or FQDNs may be required to be accessed.   |
+| Allow access to service FQDNs/IPs | No additional costs.   <br><br>  Works with all network security appliances and firewalls. <br><br> You can also use service endpoints for *Storage*. However, for *Azure Backup* and *Microsoft Entra ID*, you need to assign the access to the corresponding IPs/FQDNs. | A broad set of IPs or FQDNs might be required to be accessed.   |
 | [Virtual Network Service Endpoint](../virtual-network/virtual-network-service-endpoints-overview.md)    |     Can be used for Azure Storage.     <br><br>     Provides large benefit to optimize performance of data plane traffic.          |         Can't be used for Microsoft Entra ID, Azure Backup service.    |
 | Network Virtual Appliance      |      Can be used for Azure Storage, Microsoft Entra ID, Azure Backup service. <br><br> **Data plane**   <ul><li>      Azure Storage: `*.blob.core.windows.net`, `*.queue.core.windows.net`, `*.blob.storage.azure.net`  </li></ul>   <br><br>     **Management plane**  <ul><li>  Microsoft Entra ID: Allow access to FQDNs mentioned in sections 56 and 59 of [Microsoft 365 Common and Office Online](/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide&preserve-view=true#microsoft-365-common-and-office-online). </li><li>   Azure Backup service: `.backup.windowsazure.com` </li></ul> <br>Learn more about [Azure Firewall service tags](../firewall/fqdn-tags.md).       |  Adds overhead to data plane traffic and decrease throughput/performance.  |
 
@@ -108,6 +108,26 @@ You can also use the following FQDNs to allow access to the required services fr
 
 5. No restart of any service is required. The Azure Backup service will attempt to route the Microsoft Entra traffic via the proxy server mentioned in the JSON file.
 
+
+##### Use outbound rules
+
+If the Firewall or NSG settings block the `“management.azure.com”` domain from Azure Virtual Machine, snapshot backups will fail.
+
+Create the following outbound rule and allow the domain name to do the database backup. Learn hot to [create outbound rules](../machine-learning/how-to-access-azureml-behind-firewall.md).
+
+- **Source**: IP address of the VM.
+- **Destination**: Service Tag.
+- **Destination Service Tag**: `AzureResourceManager`
+
+:::image type="content" source="./media/backup-azure-sap-hana-database/outbound-rule-hana-backups.png" alt-text="Screenshot shows the outbound rule settings."  lightbox="./media/backup-azure-sap-hana-database/outbound-rule-hana-backups.png":::
+
+
+
+
+
+
+
+
 [!INCLUDE [How to create a Recovery Services vault](../../includes/backup-create-rs-vault.md)]
 
 ## Enable Cross Region Restore