Merge pull request #24799 from MicrosoftDocs/FromPublicRepo

Confirm merge from FromPublicRepo to main to sync with https://github.com/MicrosoftDocs/sql-docs (branch live)

Author: Taojunshen

azure-sql/database/elastic-jobs-overview.md

@@ -82,7 +82,7 @@ These are the current limitations to the Elastic Jobs service.  We're actively w
 | The Elastic Job agent needs to be recreated and started in the new region after a failover/move to a new Azure region. | The Elastic Jobs service stores all its job agent and job metadata in the jobs database. Any failover or move of Azure resources to a new Azure region will also move the jobs database, job agent and jobs metadata to the new Azure region. However, the Elastic Job agent is a compute only resource and needs to be explicitly re-created and started in the new region before jobs will start executing again in the new region. Once started, the Elastic Job agent will resume executing jobs in the new region as per the previously defined job schedule. |
 | Concurrent jobs limit. | Currently, the preview is limited to 100 concurrent jobs. |
 | Excessive Audit logs from Jobs database | The Elastic Job agent operates by constantly polling the Job database to check for the arrival of new jobs and other CRUD operations. If auditing is enabled on the server that houses a Jobs database, a large amount of audit logs may be generated by the Jobs database. This can be mitigated by filtering out these audit logs using the `Set-AzSqlServerAudit` command with a predicate expression.<BR/><BR/>For example:<BR/> `Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "database_principal_name <> '##MS_JobAccount##'"`<BR/><BR/>This command will only filter out Job Agent to Jobs database audit logs, not Job Agent to any target databases audit logs.|
-| Private end points are not supported | Databases and Elastic Pools targeted by Elastic Jobs should have "Allow Azure Services and resources to access this server" setting enabled at their server level in the current preview. If this setting is not enabled, Elastic Job Agent will not be able to execute jobs at those targets.|
+| Private endpoints are not supported | Elastic Job Agents currently cannot connect to Databases and Elastic Pools which restrict connections to private endpoints.|
 
 ## Best practices for creating jobs
 

docs/relational-databases/security/contained-database-users-making-your-database-portable.md

@@ -27,7 +27,7 @@ monikerRange: "=azuresqldb-current||>=sql-server-2016||=azure-sqldw-latest||>=sq
   
 ## Traditional Login and User Model
 
- In the traditional connection model, Windows users or members of Windows groups connect to the [!INCLUDE[ssDE](../../includes/ssde-md.md)] by providing user or group credentials authenticated by Windows. Or you can provide both a name and password and connects by using [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] authentication. In both cases, the master database must have a login that matches the connecting credentials. After the [!INCLUDE[ssDE](../../includes/ssde-md.md)] confirms the Windows authentication credentials or authenticates the [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] authentication credentials, the connection typically attempts to connect to a user database. To connect to a user database, the login must be able to be mapped to (that is, associated with) a database user in the user database. The connection string may also specify connecting to a specific database which is optional in [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] but required in [!INCLUDE[ssSDS](../../includes/sssds-md.md)].  
+ In the traditional connection model, Windows users or members of Windows groups connect to the [!INCLUDE[ssDE](../../includes/ssde-md.md)] by providing user or group credentials authenticated by Windows. Or you can provide both a name and password and connects by using [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] authentication. In both cases, the master database must have a login that matches the connecting credentials. After the [!INCLUDE[ssDE](../../includes/ssde-md.md)] confirms the Windows authentication credentials or authenticates the [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] authentication credentials, the connection typically attempts to connect to a user database. To connect to a user database, the login must be mapped to (that is, associated with) a database user in the user database. The connection string may also specify connecting to a specific database which is optional in [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] but required in [!INCLUDE[ssSDS](../../includes/sssds-md.md)].  
 
  The important principal is that both the login (in the master database) and the user (in the user database) must exist and be related to each other. This means that the connection to the user database has a dependency upon the login in the master database, and this limits the ability of the database to be moved to a different hosting [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] or [!INCLUDE[ssSDSFull](../../includes/sssdsfull-md.md)] server. And if, for any reason, a connection to the master database is not available (for example, a failover is in progress), the overall connection time will be increased or connection might time out. Consequently this may reduce connection scalability.