Merge pull request #186846 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/azure-docs (branch master)

Author: huypub

articles/active-directory/develop/msal-net-token-cache-serialization.md

@@ -116,7 +116,7 @@ services.Configure<MsalDistributedTokenCacheAdapterOptions>(options =>
 // Then, choose your implementation of distributed cache
 // -----------------------------------------------------
 
-// For instance, the distributed in-memory cache (not cleared when you stop the app)
+// good for prototyping and testing, but this is NOT persisted and it is NOT distributed - do not use in production
 services.AddDistributedMemoryCache();
 
 // Or a Redis cache
@@ -163,10 +163,10 @@ services.AddCosmosCache((CosmosCacheOptions cacheOptions) =>
 ```
 
 For more information, see:
-- [Difference between in-memory and distributed in memory caches](https://github.com/AzureAD/microsoft-identity-web/wiki/token-cache-serialization#inmemory-vs-distributedmemory-cache-options)
 - [Distributed cache advanced options](https://github.com/AzureAD/microsoft-identity-web/wiki/L1-Cache-in-Distributed-(L2)-Token-Cache)
 - [Handle L2 cache eviction](https://github.com/AzureAD/microsoft-identity-web/wiki/Handle-L2-cache-eviction)
 - [Set up a Redis cache in Docker](https://github.com/AzureAD/microsoft-identity-web/wiki/Set-up-a-Redis-cache-in-Docker)
+- [Troubleshooting](https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Cache-Troubleshooting)
 
 The usage of distributed cache is featured in the [ASP.NET Core web app tutorial](/aspnet/core/tutorials/first-mvc-app/) in the [phase 2-2 token cache](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/2-WebApp-graph-user/2-2-TokenCache).
 
@@ -276,7 +276,6 @@ You can also specify options to limit the size of the in-memory token cache:
   );
 ```
 
-
 #### Distributed caches
 
 If you use `app.AddDistributedTokenCache`, the token cache is an adapter against the .NET `IDistributedCache` implementation. So you can choose between a distributed memory cache, a SQL Server cache, a Redis cache, or an Azure Cosmos DB cache. For details about the `IDistributedCache` implementations, see [Distributed memory cache](/aspnet/core/performance/caching/distributed).
@@ -386,10 +385,10 @@ Here's the code for an Azure Cosmos DB cache:
 
 For more information about distributed caches, see:
 
-- [Difference between in-memory and distributed in-memory caches](https://github.com/AzureAD/microsoft-identity-web/wiki/token-cache-serialization#inmemory-vs-distributedmemory-cache-options)
 - [Distributed cache advanced options](https://github.com/AzureAD/microsoft-identity-web/wiki/L1-Cache-in-Distributed-(L2)-Token-Cache)
 - [Handle L2 cache eviction](https://github.com/AzureAD/microsoft-identity-web/wiki/Handle-L2-cache-eviction)
 - [Set up a Redis cache in Docker](https://github.com/AzureAD/microsoft-identity-web/wiki/Set-up-a-Redis-cache-in-Docker)
+- [Troubleshooting](https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Cache-Troubleshooting)
 
 ### Disabling a legacy token cache
 

articles/active-directory/develop/scenario-daemon-app-configuration.md

@@ -31,7 +31,7 @@ Daemon applications use application permissions rather than delegated permission
 
 The authority specified in the application configuration should be tenanted (specifying a tenant ID or a domain name associated with your organization).
 
-Even if want to provide a multitenant tool, you should use a tenant ID or domain name, and **not** `common` or `organizations` with this flow, because the service cannot reliably infer which tenant should be used.
+Even if you want to provide a multitenant tool, you should use a tenant ID or domain name, and **not** `common` or `organizations` with this flow, because the service cannot reliably infer which tenant should be used.
 
 ## Configure and instantiate the application
 

articles/active-directory/develop/tutorial-v2-nodejs-desktop.md

@@ -153,7 +153,8 @@ Create a folder to host your application, for example *ElectronDesktopApp*.
             width: 800,
             height: 600,
             webPreferences: {
-            nodeIntegration: true
+            nodeIntegration: true,
+            contextIsolation: false
             }
         });
 

articles/azure-resource-manager/management/resources-without-resource-group-limit.md

@@ -43,6 +43,7 @@ Some resources have a limit on the number instances per region. This limit is di
 * snapshots
 * virtualMachineScaleSets - By default, limited to 800 instances. That limit can be increased by contacting support.
 * virtualMachines
+* virtualMachines/extensions - Supports an unlimited number of VM extension instances.
 
 ## Microsoft.ContainerInstance
 
@@ -108,8 +109,8 @@ Some resources have a limit on the number instances per region. This limit is di
 
 ## Microsoft.HybridCompute
 
-* machines - supports up to 5,000 instances
-* machines/extensions - supports an unlimited number of VM extension instances
+* machines - Supports up to 5,000 instances.
+* machines/extensions - Supports an unlimited number of VM extension instances.
 
 ## microsoft.insights
 

articles/migrate/hyper-v-migration-architecture.md

@@ -70,7 +70,6 @@ You can limit the amount of bandwidth used to upload data to Azure on each Hyper
 2. Run **C:\Program Files\Microsoft Azure Recovery Services Agent\bin\wabadmin.msc**, to open the Windows Azure Backup MMC snap-in.
 3. In the snap-in, select **Change Properties**.
 4. In **Throttling**, select **Enable internet bandwidth usage throttling for backup operations**. Set the limits for work and non-work hours. Valid ranges are from 512 Kbps to 1,023 Mbps.
-I
 
 ### Influence upload efficiency