You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following release notes are for version 9.0.0.0 of the Azure File Sync agent (released December 2, 2019).
44
+
45
+
### Improvements and issues that are fixed
46
+
47
+
- Self-service restore support
48
+
- Users can now restore their files by using the previous version feature. Prior to the v9 release, the previous version feature was not supported on volumes that had cloud tiering enabled. This feature must be enabled for each volume separately, on which an endpoint with cloud tiering enabled exists. To learn more, see
49
+
[Self-service restore through Previous Versions and VSS (Volume Shadow Copy Service)](https://docs.microsoft.com/azure/storage/files/storage-sync-files-deployment-guide#self-service-restore-through-previous-versions-and-vss-volume-shadow-copy-service).
50
+
51
+
- Support for larger file share sizes
52
+
- Azure File Sync now supports up to 64TiB and 100 million files in a single, syncing namespace.
53
+
54
+
- Data Deduplication support on Server 2019
55
+
- Data Deduplication is now supported with cloud tiering enabled on Windows Server 2019. To support Data Deduplication on volumes with cloud tiering, Windows update [KB4520062](https://support.microsoft.com/help/4520062) must be installed.
56
+
57
+
- Improved minimum file size for a file to tier
58
+
- The minimum file size for a file to tier is now based on the file system cluster size (double the file system cluster size). For example, by default, the NTFS file system cluster size is 4KB, the resulting minimum file size for a file to tier is 8KB.
59
+
60
+
- Network connectivity test cmdlet
61
+
- As part of Azure File Sync configuration, multiple service endpoints must be contacted. They each have their own DNS name that needs to be accessible to the server. These URLs are also specific to the region a server is registered to. Once a server is registered, the connectivity test cmdlet (PowerShell and Server Registration Utility) can be used to test communications with all URLs specific to this server. This cmdlet can help troubleshoot when incomplete communication prevents the server from fully working with Azure File Sync and it can be used to fine tune proxy and firewall configurations.
62
+
63
+
To run the network connectivity test, run the following PowerShell commands:
- Remove server endpoint improvement when cloud tiering is enabled
69
+
- As before, removing a server endpoint does not result in removing files in the Azure file share. However, behavior for reparse points on the local server has changed. Reparse points (pointers to files that are not local on the server) are now deleted when removing a server endpoint. The fully cached files will remain on the server. This improvement was made to prevent [orphaned tiered files](https://docs.microsoft.com/azure/storage/files/storage-sync-files-troubleshoot?tabs=portal1%2Cazure-portal#tiered-files-are-not-accessible-on-the-server-after-deleting-a-server-endpoint) when removing a server endpoint. If the server endpoint is recreated, the reparse points for the tiered files will be recreated on the server.
70
+
71
+
- Performance and reliability improvements
72
+
- Reduced recall failures. Recall size is now automatically adjusted based on network bandwidth.
73
+
- Improved download performance when adding a new server to a sync group.
74
+
- Reduced files not syncing due to constraint conflicts.
75
+
76
+
### Evaluation Tool
77
+
Before deploying Azure File Sync, you should evaluate whether it is compatible with your system using the Azure File Sync evaluation tool. This tool is an Azure PowerShell cmdlet that checks for potential issues with your file system and dataset, such as unsupported characters or an unsupported OS version. For installation and usage instructions, see [Evaluation Tool](https://docs.microsoft.com/azure/storage/files/storage-sync-files-planning#evaluation-cmdlet) section in the planning guide.
78
+
79
+
### Agent installation and server configuration
80
+
For more information on how to install and configure the Azure File Sync agent with Windows Server, see [Planning for an Azure File Sync deployment](storage-sync-files-planning.md) and [How to deploy Azure File Sync](storage-sync-files-deployment-guide.md).
81
+
82
+
- The agent installation package must be installed with elevated (admin) permissions.
83
+
- The agent is not supported on Nano Server deployment option.
84
+
- The agent is supported only on Windows Server 2019, Windows Server 2016, and Windows Server 2012 R2.
85
+
- The agent requires at least 2 GiB of memory. If the server is running in a virtual machine with dynamic memory enabled, the VM should be configured with a minimum 2048 MiB of memory.
86
+
- The Storage Sync Agent (FileSyncSvc) service does not support server endpoints located on a volume that has the system volume information (SVI) directory compressed. This configuration will lead to unexpected results.
87
+
88
+
### Interoperability
89
+
- Antivirus, backup, and other applications that access tiered files can cause undesirable recall unless they respect the offline attribute and skip reading the content of those files. For more information, see [Troubleshoot Azure File Sync](storage-sync-files-troubleshoot.md).
90
+
- File Server Resource Manager (FSRM) file screens can cause endless sync failures when files are blocked because of the file screen.
91
+
- Running sysprep on a server that has the Azure File Sync agent installed is not supported and can lead to unexpected results. The Azure File Sync agent should be installed after deploying the server image and completing sysprep mini-setup.
92
+
93
+
### Sync limitations
94
+
The following items don't sync, but the rest of the system continues to operate normally:
95
+
- Files with unsupported characters. See [Troubleshooting guide](storage-sync-files-troubleshoot.md#handling-unsupported-characters) for list of unsupported characters.
96
+
- Files or directories that end with a period.
97
+
- Paths that are longer than 2,048 characters.
98
+
- The discretionary access control list (DACL) portion of a security descriptor if it's larger than 2 KB. (This issue applies only when you have more than about 40 access control entries (ACEs) on a single item.)
99
+
- The system access control list (SACL) portion of a security descriptor that's used for auditing.
100
+
- Extended attributes.
101
+
- Alternate data streams.
102
+
- Reparse points.
103
+
- Hard links.
104
+
- Compression (if it's set on a server file) isn't preserved when changes sync to that file from other endpoints.
105
+
- Any file that's encrypted with EFS (or other user mode encryption) that prevents the service from reading the data.
106
+
107
+
> [!Note]
108
+
> Azure File Sync always encrypts data in transit. Data is always encrypted at rest in Azure.
109
+
110
+
### Server endpoint
111
+
- A server endpoint can be created only on an NTFS volume. ReFS, FAT, FAT32, and other file systems aren't currently supported by Azure File Sync.
112
+
- Tiered files will become inaccessible if the files are not recalled prior to deleting the server endpoint. To restore access to the files, recreate the server endpoint. If 30 days have passed since the server endpoint was deleted or if the cloud endpoint was deleted, tiered files that were not recalled will be unusable. To learn more, see [Tiered files are not accessible on the server after deleting a server endpoint](https://docs.microsoft.com/azure/storage/files/storage-sync-files-troubleshoot?tabs=portal1%2Cazure-portal#tiered-files-are-not-accessible-on-the-server-after-deleting-a-server-endpoint).
113
+
- Cloud tiering is not supported on the system volume. To create a server endpoint on the system volume, disable cloud tiering when creating the server endpoint.
114
+
- Failover Clustering is supported only with clustered disks, but not with Cluster Shared Volumes (CSVs).
115
+
- A server endpoint can't be nested. It can coexist on the same volume in parallel with another endpoint.
116
+
- Do not store an OS or application paging file within a server endpoint location.
117
+
- The server name in the portal is not updated if the server is renamed.
118
+
119
+
### Cloud endpoint
120
+
- Azure File Sync supports making changes to the Azure file share directly. However, any changes made on the Azure file share first need to be discovered by an Azure File Sync change detection job. A change detection job is initiated for a cloud endpoint once every 24 hours. To immediately sync files that are changed in the Azure file share, the [Invoke-AzStorageSyncChangeDetection](https://docs.microsoft.com/powershell/module/az.storagesync/invoke-azstoragesyncchangedetection) PowerShell cmdlet can be used to manually initiate the detection of changes in the Azure file share. In addition, changes made to an Azure file share over the REST protocol will not update the SMB last modified time and will not be seen as a change by sync.
121
+
- The storage sync service and/or storage account can be moved to a different resource group or subscription within the existing Azure AD tenant. If the storage account is moved, you need to give the Hybrid File Sync Service access to the storage account (see [Ensure Azure File Sync has access to the storage account](https://docs.microsoft.com/azure/storage/files/storage-sync-files-troubleshoot?tabs=portal1%2Cportal#troubleshoot-rbac)).
122
+
123
+
> [!Note]
124
+
> Azure File Sync does not support moving the subscription to a different Azure AD tenant.
125
+
126
+
### Cloud tiering
127
+
- If a tiered file is copied to another location by using Robocopy, the resulting file isn't tiered. The offline attribute might be set because Robocopy incorrectly includes that attribute in copy operations.
128
+
- When copying files using robocopy, use the /MIR option to preserve file timestamps. This will ensure older files are tiered sooner than recently accessed files.
129
+
41
130
## Agent version 8.0.0.0
42
131
The following release notes are for version 8.0.0.0 of the Azure File Sync agent (released October 8, 2019).
Copy file name to clipboardExpand all lines: includes/storage-sync-files-scale-targets.md
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,12 +17,11 @@
17
17
| Cloud endpoints per sync group | 1 cloud endpoint | Yes |
18
18
| Server endpoints per sync group | 50 server endpoints | No |
19
19
| Server endpoints per server | 30 server endpoints | Yes |
20
-
| File system objects (directories and files) per sync group |50 million objects | No |
20
+
| File system objects (directories and files) per sync group |100 million objects | No |
21
21
| Maximum number of file system objects (directories and files) in a directory | 5 million objects | Yes |
22
22
| Maximum object (directories and files) security descriptor size | 64 KiB | Yes |
23
23
| File size | 100 GiB | No |
24
-
| Minimum file size for a file to be tiered | 64 KiB | Yes |
25
-
| Concurrent sync sessions | V4 agent and later: The limit varies based on available system resources. <BR> V3 agent: Two active sync sessions per processor or a maximum of eight active sync sessions per server. | Yes
24
+
| Minimum file size for a file to be tiered | V9: Based on file system cluster size (double file system cluster size). For example, if the file system cluster size is 4kb, the minimum file size will be 8kb.<br> V8 and older: 64 KiB | Yes |
26
25
27
26
> [!Note]
28
27
> 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.
0 commit comments