Merge pull request #234581 from jeffpatt24/patch-5

Update storage-files-scale-targets.md

Author: Stacyrch140

articles/storage/file-sync/file-sync-troubleshoot-installation.md

@@ -15,30 +15,61 @@ After deploying the Storage Sync Service, the next steps in deploying Azure File
 
 ## Agent installation
 <a id="agent-installation-failures"></a>**Troubleshoot agent installation failures**  
-If the Azure File Sync agent installation fails, at an elevated command prompt, run the following command to turn on logging during agent installation:
+If the Azure File Sync agent installation fails, locate the installation log file which is located in the agent installation directory. If the Azure File Sync agent is installed on the C: volume, the installation log file is located under C:\Program Files\Azure\StorageSyncAgent\InstallerLog. 
 
+> [!Note]  
+> If the Azure File Sync agent is installed from the command line and the /l\*v switch is used, the log file will be located in the path where the agent installation was executed. 
+
+The log file name for agent installations using the MSI package is AfsAgentInstall. The log file name for agent installations using the MSP package (update package) is AfsUpdater.
+
+Once you have located the agent installation log file, open the file and search for the failure code at the end of the log. If you search for **error code 1603** or **sandbox**, you should be able to locate the error code. 
+
+Here is a snippet from an agent installation that failed:
 ```
-StorageSyncAgent.msi /l*v AFSInstaller.log
+CAQuietExec64:      + CategoryInfo          : SecurityError: (:) , PSSecurityException  
+CAQuietExec64:      + FullyQualifiedErrorId : UnauthorizedAccess  
+CAQuietExec64:  Error 0x80070001: Command line returned an error.  
+CAQuietExec64:  Error 0x80070001: QuietExec64 Failed  
+CAQuietExec64:  Error 0x80070001: Failed in ExecCommon64 method  
+CustomAction SetRegPIIAclSettings returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)  
+Action ended 12:23:40: InstallExecute. Return value 3.  
+MSI (s) (0C:C8) [12:23:40:994]: Note: 1: 2265 2:  3: -2147287035
 ```
 
-Review installer.log to determine the cause of the installation failure.
+For this example, the agent installation failed with error code -2147287035 (ERROR_ACCESS_DENIED). 
 
 <a id="agent-installation-gpo"></a>**Agent installation fails with error: Storage Sync Agent Setup Wizard ended prematurely because of an error**
 
 In the agent installation log, the following error is logged:
 
 ```
-CAQuietExec64:  + CategoryInfo          : SecurityError: (:) , PSSecurityException
-CAQuietExec64:  + FullyQualifiedErrorId : UnauthorizedAccess
-CAQuietExec64:  Error 0x80070001: Command line returned an error.
+CAQuietExec64:      + CategoryInfo          : SecurityError: (:) , PSSecurityException  
+CAQuietExec64:      + FullyQualifiedErrorId : UnauthorizedAccess  
+CAQuietExec64:  Error 0x80070001: Command line returned an error.  
+CAQuietExec64:  Error 0x80070001: QuietExec64 Failed  
+CAQuietExec64:  Error 0x80070001: Failed in ExecCommon64 method  
+CustomAction SetRegPIIAclSettings returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)  
+Action ended 12:23:40: InstallExecute. Return value 3.  
+MSI (s) (0C:C8) [12:23:40:994]: Note: 1: 2265 2:  3: -2147287035 
 ```
 
 This issue occurs if the [PowerShell execution policy](/powershell/module/microsoft.powershell.core/about/about_execution_policies#use-group-policy-to-manage-execution-policy) is configured using group policy and the policy setting is "Allow only signed scripts." All scripts included with the Azure File Sync agent are signed. The Azure File Sync agent installation fails because the installer is performing the script execution using the Bypass execution policy setting.
 
 To resolve this issue, temporarily disable the [Turn on Script Execution](/powershell/module/microsoft.powershell.core/about/about_execution_policies#use-group-policy-to-manage-execution-policy) group policy setting on the server. Once the agent installation completes, the group policy setting can be re-enabled.
 
 <a id="agent-installation-on-DC"></a>**Agent installation fails on Active Directory Domain Controller**  
-If you try to install the sync agent on an Active Directory domain controller where the PDC role owner is on a Windows Server 2008 R2 or below OS version, you may hit the issue where the sync agent will fail to install.
+
+In the agent installation log, the following error is logged:
+
+```
+CAQuietExec64:  Error 0x80070001: Command line returned an error.
+CAQuietExec64:  Error 0x80070001: CAQuietExec64 Failed
+CustomAction InstallHFSRequiredWindowsFeatures returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
+Action ended 8:51:12: InstallExecute. Return value 3.
+MSI (s) (EC:B4) [08:51:12:439]: Note: 1: 2265 2:  3: -2147287035
+```
+
+This issue occurs if you try to install the sync agent on an Active Directory domain controller where the PDC role owner is on a Windows Server 2008 R2 or below OS version.
 
 To resolve, transfer the PDC role to another domain controller running Windows Server 2012 R2 or more recent, then install sync.
 

articles/storage/file-sync/file-sync-troubleshoot-sync-errors.md

@@ -20,7 +20,9 @@ This article is designed to help you troubleshoot and resolve common sync issues
 [!INCLUDE [storage-sync-files-change-detection](../../../includes/storage-sync-files-change-detection.md)]
 
 <a id="serverendpoint-pending"></a>**Server endpoint health is in a pending state for several hours**  
-This issue is expected if you create a cloud endpoint and use an Azure file share that contains data. The change enumeration job that scans for changes in the Azure file share must complete before files can sync between the cloud and server endpoints. The time to complete the job is dependent on the size of the namespace in the Azure file share. The server endpoint health should update once the change enumeration job completes.
+This issue is expected if you create a cloud endpoint and use an Azure file share that contains data. The cloud change enumeration job that scans for changes in the Azure file share must complete before files can sync between the cloud and server endpoints. The time to complete the job is dependent on the size of the namespace in the Azure file share. The server endpoint health should update once the change enumeration job completes.
+
+To check the status of the cloud change enumeration job, go the Cloud Endpoint properties in the portal and the status is provided in the Change Enumeration section.
 
 ### <a id="broken-sync"></a>How do I monitor sync health?
 # [Portal](#tab/portal1)
@@ -781,7 +783,7 @@ Server endpoint provisioning fails with this error code if these conditions are
 * This server endpoint was provisioned with the initial sync mode: [server authoritative](file-sync-server-endpoint-create.md#initial-sync-section)
 * Local server path is empty or contains no items recognized as able to sync.
 
-This provisioning error protects you from deleting all content that might be available in an Azure file share. Server authoritative upload is a special mode to catch up a cloud location that was already seeded, with the updates from the server location. Review this [migration guide](../files/storage-files-migration-server-hybrid-databox.md) to understand the scenario for which this mode has been built for.
+This provisioning error protects you from deleting all content that might be available in an Azure file share. Server authoritative upload is a special mode to catch up a cloud location that was already seeded, with the updates from the server location. Review this [migration guide](../files/storage-files-migration-server-hybrid-databox.md) to understand the scenario for which this mode has been built.
 
 1. Remove the server endpoint in the sync group by following the steps documented in [Remove a server endpoint](file-sync-server-endpoint-delete.md).
 1. Create a new server endpoint in the sync group by following the steps documented in [Add a server endpoint](file-sync-server-endpoint-create.md).

articles/storage/files/storage-files-faq.md

@@ -25,6 +25,13 @@ ms.topic: conceptual
 
 * <a id="afs-conflict-resolution"></a>
   **If the same file is changed on two servers at approximately the same time, what happens?**  
+    File conflicts are created when the file in the Azure file share doesn't match the file in the server endpoint location (size and/or last modified time is different). 
+    
+    The following scenarios can cause file conflicts:
+    - A file is created or modified in an endpoint (for example, Server A). If the same file is modified on a different endpoint before the change on Server A is synced to that endpoint, a conflict file is created.  
+    - The file existed in the Azure file share and server endpoint location prior to the server endpoint creation. If the file size and/or last modified time is different between the file on the server and Azure file share when the server endpoint is created, a conflict file is created.  
+    - Sync database was recreated due to corruption or knowledge limit reached. Once the database is recreated, sync enters a mode called reconciliation. If the file size and/or last modified time is different between the file on the server and Azure file share when reconciliation occurs, a conflict file is created. 
+  
     Azure File Sync uses a simple conflict-resolution strategy: we keep both changes to files that are changed in two endpoints at the same time. The most recently written change keeps the original file name. The older file (determined by LastWriteTime) has the endpoint name and the conflict number appended to the file name. For server endpoints, the endpoint name is the name of the server. For cloud endpoints, the endpoint name is **Cloud**. The name follows this taxonomy:
 
     \<FileNameWithoutExtension\>-\<endpointName\>\[-#\].\<ext\>  

articles/storage/files/storage-files-scale-targets.md

@@ -90,7 +90,7 @@ File scale targets apply to individual files stored in Azure file shares.
 <sup>3 Azure Files supports 2,000 open handles per share, and in practice can go higher. However, if an application keeps an open handle on the root of the share, the share root limit will be reached before the per-file or per-directory limit is reached.</sup>
 
 ## Azure File Sync scale targets
-The following table indicates which target are soft, representing the Microsoft tested boundary, and hard, indicating an enforced maximum:
+The following table indicates which targets are soft, representing the Microsoft tested boundary, and hard, indicating an enforced maximum:
 
 | Resource | Target | Hard limit |
 |----------|--------------|------------|
@@ -109,7 +109,7 @@ The following table indicates which target are soft, representing the Microsoft
 > [!Note]  
 > An Azure File Sync endpoint can scale up to the size of an Azure file share. If the Azure file share size limit is reached, sync will not be able to operate.
 
-### Azure File Sync performance metrics
+## Azure File Sync performance metrics
 Since the Azure File Sync agent runs on a Windows Server machine that connects to the Azure file shares, the effective sync performance depends upon a number of factors in your infrastructure: Windows Server and the underlying disk configuration, network bandwidth between the server and the Azure storage, file size, total dataset size, and the activity on the dataset. Since Azure File Sync works on the file level, the performance characteristics of an Azure File Sync-based solution should be measured by the number of objects (files and directories) processed per second.
 
 For Azure File Sync, performance is critical in two stages:
@@ -119,7 +119,8 @@ For Azure File Sync, performance is critical in two stages:
 > [!Note]  
 > When many server endpoints in the same sync group are syncing at the same time, they are contending for cloud service resources. As a result, upload performance will be impacted. In extreme cases, some sync sessions will fail to access the resources, and will fail. However, those sync sessions will resume shortly and eventually succeed once the congestion is reduced. 
 
-To help you plan your deployment for each of the stages, below are the results observed during the internal testing on a system with a config
+## Internal test results
+To help you plan your deployment for each of the stages (initial one-time provisioning and ongoing sync), below are the results observed during the internal testing on a system with the following configuration:
 
 | System configuration | Details |
 |-|-|
@@ -129,6 +130,8 @@ To help you plan your deployment for each of the stages, below are the results o
 | Network | 1 Gbps Network |
 | Workload | General Purpose File Server|
 
+### Initial one-time provisioning
+
 | Initial one-time provisioning  | Details |
 |-|-|
 | Number of objects | 25 million objects |
@@ -138,8 +141,6 @@ To help you plan your deployment for each of the stages, below are the results o
 | Upload Throughput | 20 objects per second per sync group |
 | Namespace Download Throughput | 400 objects per second |
 
-### Initial one-time provisioning
-
 **Initial cloud change enumeration**: When a new sync group is created, initial cloud change enumeration is the first step that will execute. In this process, the system will enumerate all the items in the Azure File Share. During this process, there will be no sync activity i.e. no items will be downloaded from cloud endpoint to server endpoint and no items will be uploaded from server endpoint to cloud endpoint. Sync activity will resume once initial cloud change enumeration completes.
 The rate of performance is 80 objects per second. Customers can estimate the time it will take to complete initial cloud change enumeration by determining the number of items in the cloud share and using the following formulae to get the time in days. 
 
@@ -157,6 +158,8 @@ Splitting your data into multiple server endpoints and sync groups can speed up
 
 **Namespace download throughput** When a new server endpoint is added to an existing sync group, the Azure File Sync agent does not download any of the file content from the cloud endpoint. It first syncs the full namespace and then triggers background recall to download the files, either in their entirety or, if cloud tiering is enabled, to the cloud tiering policy set on the server endpoint.
 
+### Ongoing sync
+
 | Ongoing sync  | Details  |
 |-|--|
 | Number of objects synced| 125,000 objects (~1% churn) |