Merge pull request #48127 from MicrosoftDocs/repo_sync_working_branch

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

Author: huypub

articles/active-directory/connect/active-directory-aadconnect-version-history.md

@@ -36,7 +36,7 @@ Download| [Download Azure AD Connect](http://go.microsoft.com/fwlink/?LinkId=615
 
 ### Release status
 
-7/20/2018: Released for auto upgrade. Release for download will follow shortly.
+7/20/2018: Released for download and auto upgrade. The auto upgrade process is still in progress.
 
 ### New features and improvements
 

articles/service-fabric/service-fabric-cluster-capacity.md

@@ -58,7 +58,7 @@ The Service Fabric system services (for example, the Cluster Manager service or
 * The **minimum size of VMs** for the primary node type is determined by the **durability tier** you choose. The default durability tier is Bronze. See [The durability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-durability-characteristics-of-the-cluster) for more details.  
 * The **minimum number of VMs** for the primary node type is determined by the **reliability tier** you choose. The default reliability tier is Silver. See [The reliability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-reliability-characteristics-of-the-cluster) for more details.  
 
-From the Azure Resource Manager template, the primary node type is configured with the `isPrimary` attribute under the [node type definition](https://docs.microsoft.com/en-us/azure/templates/microsoft.servicefabric/clusters#nodetypedescription-object).
+From the Azure Resource Manager template, the primary node type is configured with the `isPrimary` attribute under the [node type definition](https://docs.microsoft.com/azure/templates/microsoft.servicefabric/clusters#nodetypedescription-object).
 
 ### Non-primary node type
 
@@ -106,10 +106,6 @@ Use Silver or Gold durability for all node types that host stateful services you
 - Adopt safer ways to make a VM SKU change (Scale up/down): Changing the VM SKU of a virtual machine scale set is inherently an unsafe operation and so should be avoided if possible. Here is the process you can follow to avoid common issues.
 	- **For non-primary node types:** It is recommended that you create new virtual machine scale set, modify the service placement constraint to include the new virtual machine scale set/node type and then reduce the old virtual machine scale set instance count to 0, one node at a time (this is to make sure that removal of the nodes do not impact the reliability of the cluster).
 	- **For the primary node type:** Our recommendation is that you do not change VM SKU of the primary node type. Changing of the primary node type SKU is not supported. If the reason for the new SKU is capacity, we recommend adding more instances. If that not possible, create a new cluster and [restore application state](service-fabric-reliable-services-backup-restore.md) (if applicable) from your old cluster. You do not need to restore any system service state, they are recreated when you deploy your applications to your new cluster. If you were just running stateless applications on your cluster, then all you do is deploy your applications to the new cluster, you have nothing to restore. If you decide to go the unsupported route and want to change the VM SKU, then make modifications to the virtual machine scale set Model definition to reflect the new SKU. If your cluster has only one node type, then make sure that all your stateful applications respond to all [Service replica lifecycle events](service-fabric-reliable-services-lifecycle.md) (like replica in build is stuck) in a timely fashion and that your service replica rebuild duration is less than five minutes (for Silver durability level). 
-
-    > [!WARNING]
-    > Changing the VM SKU Size for virtual machine scale sets not running at least Silver durability is not recommended. Changing VM SKU Size is a data-destructive in-place infrastructure operation. Without at least some ability to delay or monitor this change, it is possible that the operation can cause data loss for stateful services or cause other unforeseen operational issues, even for stateless workloads. 
-    > 
 
 - Maintain a minimum count of five nodes for any virtual machine scale set that has durability level of Gold or Silver enabled.
 - Each VM scale set with durability level Silver or Gold must map to its own node type in the Service Fabric cluster. Mapping multiple VM scale sets to a single node type will prevent coordination between the Service Fabric cluster and the Azure infrastructure from working properly.

articles/sql-database/sql-database-connectivity-architecture.md

@@ -45,7 +45,8 @@ If you are connecting from outside Azure, your connections have a connection pol
 ![architecture overview](./media/sql-database-connectivity-architecture/connectivity-from-outside-azure.png)
 
 > [!IMPORTANT]
-> When using service endpoints with Azure SQL Database your policy is **Redirect** by default. So to enable connectivity from inside your Vnet you must allow outbound to all Azure SQL Database IP addresses, not just the gateway IPs. This can be done with the help of NSG (Network Security Group) Service Tags, if you want to allow outbound only to gateway IPs please change your setting to **Proxy**.
+> When using service endpoints with Azure SQL Database your policy is **Proxy** by default. To enable connectivity from inside your Vnet, allow outbound connections to the Azure SQL Database Gateway IP addresses specified in the list below. 
+When using service endpoints we highly recommend changing your connection policy to **Redirect** to enable better performance. If you change your connection policy to **Redirect** it will not be sufficient to allow outbound on your NSG to Azure SQLDB gateway IPs listed below, you must allow outbound to all Azure SQLDB IPs. This can be accomplished with the help of NSG (Network Security Groups) Service Tags. For more information, see [Service Tags](https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags).
 
 ## Azure SQL Database gateway IP addresses
 

articles/sql-database/sql-database-vcore-resource-limits-elastic-pools.md

@@ -143,4 +143,5 @@ The following table describes the properties for pooled databases.
 ## Next steps
 
 - See [SQL Database FAQ](sql-database-faq.md) for answers to frequently asked questions.
+- See [Overview Azure SQL Database resource limits](sql-database-resource-limits.md) for information about limits at the server and subscription levels.
 - For information about general Azure limits, see [Azure subscription and service limits, quotas, and constraints](../azure-subscription-service-limits.md).