Broke a link in the renaming, also addressing some Acrolinx feedback.

Author: fauhse

articles/storage/files/storage-files-migration-storsimple-1200.md

@@ -53,13 +53,13 @@ The previous image depicts steps that correspond to sections in this article.
 ### Step 2: Configure your Windows Server storage
 
 In this step, you map your StorSimple storage structure (volumes and shares) to your Windows Server storage structure.
-If you plan to make changes to your storage structure, meaning the number of volumes, the association of data folders to volumes, or the subfolder structure above or below your current SMB/NFS shares, then now is the time to take this into consideration.
+If you plan to make changes to your storage structure, meaning the number of volumes, the association of data folders to volumes, or the subfolder structure above or below your current SMB/NFS shares, then now is the time to take these changes into consideration.
 Changing your file and folder structure after Azure File Sync is configured, is cumbersome, and should be avoided.
 This article assumes you are mapping 1:1, so you must take your mapping changes into consideration when you follow the steps in this article.
 
 * None of your production data should end up on the Windows Server system volume. Cloud tiering is not supported on system volumes. However, this feature is required for the migration as well as continuous operations as a StorSimple replacement.
 * Provision the same number of volumes on your Windows Server as you have on your StorSimple 1200 virtual appliance.
-* Configure any Windows Server roles, features, and settings you need. We recommend you opt into Windows Server updates to keep your OS safe and up to date. Similarly, we recommend opting into Microsoft Update to keep Microsoft applications up to date, this includes the Azure File Sync agent.
+* Configure any Windows Server roles, features, and settings you need. We recommend you opt into Windows Server updates to keep your OS safe and up to date. Similarly, we recommend opting into Microsoft Update to keep Microsoft applications up to date, including the Azure File Sync agent.
 * Do not configure any folders or shares before reading the following steps.
 
 ### Step 3: Deploy the first Azure File Sync cloud resource
@@ -106,7 +106,7 @@ Run the first local copy to your Windows Server target folder:
 * Identify the matching folder on the Windows Server, that already has Azure File Sync configured on it.
 * Start the copy using RoboCopy
 
-The following RoboCopy command will recall files from your StorSimple Azure storage to your local StorSimple and then move them over to the Windows Server target folder. The Windows Server will sync it to the Azure file share(s). As the local Windows Server volume gets full, cloud tiering will kick in and tier files that have successfully synced already. This will generate enough space to continue the copy from the StorSimple virtual appliance. Cloud tiering checks once an hour to see what has synced and to free up disk space to reach the 99% volume free space.
+The following RoboCopy command will recall files from your StorSimple Azure storage to your local StorSimple and then move them over to the Windows Server target folder. The Windows Server will sync it to the Azure file share(s). As the local Windows Server volume gets full, cloud tiering will kick in and tier files that have successfully synced already. Cloud tiering will generate enough space to continue the copy from the StorSimple virtual appliance. Cloud tiering checks once an hour to see what has synced and to free up disk space to reach the 99% volume free space.
 
 ```console
 Robocopy /MIR /COPYALL /DCOPY:DAT <SourcePath> <Dest.Path>
@@ -176,7 +176,7 @@ You can try to run a few of these copies in parallel. We recommend processing th
 > [!WARNING]
 > Once you have moved all the data from you StorSimple to the Windows Server, and your migration is complete: Return to ***all***  sync groups in the Azure portal and adjust the cloud tiering volume free space percent value to something better suited for cache utilization, say 20%. 
 
-The cloud tiering volume free space policy acts on a volume level with potentially multiple server endpoints syncing from it. If you forget to adjust the free space on even one server endpoint, sync will continue to apply the most restrictive rule and attempt to keep 99% free disk space, making the local cache not very usable. Unless it is your goal to only have the namespace for a volume that only contains rarely accessed, archival data.
+The cloud tiering volume free space policy acts on a volume level with potentially multiple server endpoints syncing from it. If you forget to adjust the free space on even one server endpoint, sync will continue to apply the most restrictive rule and attempt to keep 99% free disk space, making the local cache not performing as you might expect. Unless it is your goal to only have the namespace for a volume that only contains rarely accessed, archival data.
 
 ## Troubleshoot
 
@@ -193,7 +193,7 @@ As unlikely as they may be, if that happens, take a look at the **LINK Azure Fil
 
 Migration content:
 
-* [StorSimple 8000 series migration guide](storage-files-migration-ss8000.md)
+* [StorSimple 8000 series migration guide](storage-files-migration-storsimple-8000.md)
 
 Azure File Sync content:
 

articles/storage/files/storage-files-migration-storsimple-8000.md

@@ -24,7 +24,7 @@ This article provides the necessary background knowledge and migrations steps to
 Azure File Sync is a Microsoft cloud service, based on two main components:
 
 * File synchronization and cloud tiering.
-* File shares as native storage in Azure, that can be accessed over multiple protocols like SMB and file REST. An Azure file share is comparable to a file share on a Windows Server, that you can natively mount as a network drive. It supports important file fidelity aspects like attributes, permissions, and timestamps. With Azure file shares there is no longer a need for an application or service to interpret the files and folders stored in the cloud. You can access them natively over familiar protocols and clients like Windows File Explorer. That makes Azure file share the ideal, and most flexible approach to store general purpose file server data as well as some application data, in the cloud.
+* File shares as native storage in Azure, that can be accessed over multiple protocols like SMB and file REST. An Azure file share is comparable to a file share on a Windows Server, that you can natively mount as a network drive. It supports important file fidelity aspects like attributes, permissions, and timestamps. With Azure file shares there is no longer a need for an application or service to interpret the files and folders stored in the cloud. You can access them natively over familiar protocols and clients like Windows File Explorer. That makes Azure file shares the ideal, and most flexible approach to store general purpose file server data as well as some application data, in the cloud.
 
 This article focuses on the migration steps. If before migrating you'd like to learn more about Azure File Sync, we recommend the following articles:
 
@@ -57,7 +57,7 @@ The sequence is as follows:
 * Determine the minimum set of volume clones you must migrate. We recommend keeping this list to a minimum if possible, because the more backups you migrate the longer the overall migration process will take.
 * When going through the migration process, begin with the oldest volume clone you intend to migrate and on each subsequent migration, use the next oldest.
 * When each volume clone migration completes, you must take an Azure file share snapshot. [Azure file share snapshots](storage-snapshots-files.md) are how you keep point-in-time backups of the files and folder structure for your Azure file shares. You will need these snapshots after the migration completes, to ensure you have preserved versions of each of your volume clones as you progress through the migration.
-* Ensure that you take Azure file share snapshots for all Azure file shares, that are served by the same StorSimple volume. Volume clones are on the volume level, Azure file share snapshots are on the share level. You need to take a share snapshots after the migration of each volume clone is finished.
+* Ensure that you take Azure file share snapshots for all Azure file shares, that are served by the same StorSimple volume. Volume clones are on the volume level, Azure file share snapshots are on the share level. You need to take a share snapshot (on each Azure file share) after the migration of a volume clone is finished.
 * Repeat the migration process for a volume clone and taking share snapshots after each volume clone until you get caught up to a snapshot of the live data. The process of migrating a volume clone is described in the phases below. 
 
 If you do not need to move backups at all and can start a new chain of backups on the Azure file share side after the migration of only the live data is done, then that is beneficial to reduce complexity in the migration and amount of time the migration will take. You can make the decision whether or not to move backups and how many for each volume (not each share) you have in StorSimple.
@@ -182,7 +182,7 @@ Only proceed to phase 3 when you have completed these steps for all the volumes
 
 ### Deploy the Azure File Sync cloud resource
 
-[!INCLUDE [storage-files-migration-deploy-afs-sss](../../../includes/storage-files-migration-deploy-azure-file-sync-storage-sync-services.md)]
+[!INCLUDE [storage-files-migration-deploy-afs-sss](../../../includes/storage-files-migration-deploy-azure-file-sync-storage-sync-service.md)]
 
 > [!TIP]
 > If you need to change the Azure region from the current region your StorSimple data resides in, then you have provisioned the storage accounts for your Azure file shares in the new region. Make sure that you selected that same region when you deploy this Storage Sync Service.
@@ -377,7 +377,7 @@ Background:
       /COPY:copyflag[s]
    :::column-end:::
    :::column span="1":::
-      fidelity of the file copy (default is /COPY:DAT), copy flags : D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info
+      fidelity of the file copy (default is /COPY:DAT), copy flags: D=Data, A=Attributes, T=Timestamps, S=Security=NTFS ACLs, O=Owner info, U=aUditing info
    :::column-end:::
 :::row-end:::
 :::row:::
@@ -393,7 +393,7 @@ Background:
       /DCOPY:copyflag[s]
    :::column-end:::
    :::column span="1":::
-      fidelity for the copy of directories (default is /DCOPY:DA), copy flags : D=Data, A=Attributes, T=Timestamps
+      fidelity for the copy of directories (default is /DCOPY:DA), copy flags: D=Data, A=Attributes, T=Timestamps
    :::column-end:::
 :::row-end:::