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
| V13 Release | 13.0.0.0 | N/A | Not Supported - Agent versions expired on August 8, 2022 |
33
33
| V12 Release | 12.0.0.0 - 12.1.0.0 | N/A | Not Supported - Agent versions expired on May 23, 2022 |
34
34
| V11 Release | 11.1.0.0 - 11.3.0.0 | N/A | Not Supported - Agent versions expired on March 28, 2022 |
35
35
| V10 Release | 10.0.0.0 - 10.1.0.0 | N/A | Not Supported - Agent versions expired on June 28, 2021 |
@@ -218,86 +218,3 @@ The following items don't sync, but the rest of the system continues to operate
218
218
### Cloud tiering
219
219
- 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.
220
220
- 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.
221
-
222
-
## Agent version 13.0.0.0
223
-
The following release notes are for version 13.0.0.0 of the Azure File Sync agent (released July 12, 2021).
224
-
225
-
### Improvements and issues that are fixed
226
-
- Authoritative upload
227
-
- Authoritative upload is a new mode available when creating the first server endpoint in a sync group. It is useful for the scenario where the cloud (Azure file share) has some/most of the data but is outdated and needs to be caught up with the more recent data on the new server endpoint. This is the case in offline migration scenarios like DataBox, for instance. When a DataBox is filled and sent to Azure, the users of the local server will keep changing / adding / deleting files on the local server. That makes the data in the DataBox and thus the Azure file share, slightly outdated. With Authoritative Upload, you can now tell the server and cloud, how to resolve this case and get the cloud seamlessly updated with the latest changes on the server.
228
-
229
-
No matter how the data got to the cloud, this mode can update the Azure file share if the data stems from the matching location on the server. Be sure to avoid large directory restructures between the initial copy to the cloud and catching up with Authoritative Upload. This will ensure you are only transporting updates. Changes to directory names will cause all files in these renamed directories to be uploaded again. This functionality is comparable to semantics of RoboCopy /MIR = mirror source to target, including removing files on the target that no longer exist on the source.
230
-
231
-
Authoritative Upload replaces the "Offline Data Transfer" feature for DataBox integration with Azure File Sync via a staging share. A staging share is no longer required to use DataBox. New Offline Data Transfer jobs can no longer be started with the AFS V13 agent. Existing jobs on a server will continue even with the upgrade to agent version 13.
232
-
233
-
- Portal improvements to view cloud change enumeration and sync progress
234
-
- When a new sync group is created, any connected server endpoint can only begin sync, when cloud change enumeration is complete. In case files already exist in the cloud endpoint (Azure file share) of this sync group, change enumeration of content in the cloud can take some time. The more items (files and folders) exist in the namespace, the longer this process can take. Admins will now be able to obtain cloud change enumeration progress in the Azure portal to estimate an eta for completion / sync to start with servers.
235
-
236
-
- Support for server rename
237
-
- If a registered server is renamed, Azure File Sync will now show the new server name in the portal. If the server was renamed prior to the v13 release, the server name in the portal will now be updated to show the correct server name.
238
-
239
-
- Support for Windows Server 2022
240
-
- The Azure File Sync agent is now supported on Windows Server 2022.
241
-
242
-
> [!Note]
243
-
> Windows Server 2022 adds support for TLS 1.3 which is not currently supported by Azure File Sync. If the [TLS settings](/windows-server/security/tls/tls-ssl-schannel-ssp-overview) are managed via group policy, the server must be configured to support TLS 1.2.
244
-
245
-
- Miscellaneous improvements
246
-
- Reliability improvements for sync, cloud tiering and cloud change enumeration.
247
-
- If a large number of files is changed on the server, sync upload is now performed from a VSS snapshot which reduces per-item errors and sync session failures.
248
-
- The Invoke-StorageSyncFileRecall cmdlet will now recall all tiered files associated with a server endpoint, even if the file has moved outside the server endpoint location.
249
-
- Explorer.exe is now excluded from cloud tiering last access time tracking.
250
-
- New telemetry (Event ID 6664) to monitor the orphaned tiered files cleanup progress after removing a server endpoint with cloud tiering enabled.
251
-
252
-
253
-
### Evaluation Tool
254
-
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](file-sync-planning.md#evaluation-cmdlet) section in the planning guide.
255
-
256
-
### Agent installation and server configuration
257
-
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](file-sync-planning.md) and [How to deploy Azure File Sync](file-sync-deployment-guide.md).
258
-
259
-
- A restart is required for servers that have an existing Azure File Sync agent installation if the agent version is less than version 12.0.
260
-
- The agent installation package must be installed with elevated (admin) permissions.
261
-
- The agent is not supported on Nano Server deployment option.
262
-
- The agent is supported only on Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and Windows Server 2022.
263
-
- 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. See [Recommended system resources](file-sync-planning.md#recommended-system-resources) for more information.
264
-
- 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.
265
-
266
-
### Interoperability
267
-
- 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](file-sync-troubleshoot.md).
268
-
- File Server Resource Manager (FSRM) file screens can cause endless sync failures when files are blocked because of the file screen.
269
-
- 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.
270
-
271
-
### Sync limitations
272
-
The following items don't sync, but the rest of the system continues to operate normally:
273
-
- Files with unsupported characters. See [Troubleshooting guide](file-sync-troubleshoot.md#handling-unsupported-characters) for list of unsupported characters.
274
-
- Files or directories that end with a period.
275
-
- Paths that are longer than 2,048 characters.
276
-
- The system access control list (SACL) portion of a security descriptor that's used for auditing.
277
-
- Extended attributes.
278
-
- Alternate data streams.
279
-
- Reparse points.
280
-
- Hard links.
281
-
- Compression (if it's set on a server file) isn't preserved when changes sync to that file from other endpoints.
282
-
- Any file that's encrypted with EFS (or other user mode encryption) that prevents the service from reading the data.
283
-
284
-
> [!Note]
285
-
> Azure File Sync always encrypts data in transit. Data is always encrypted at rest in Azure.
286
-
287
-
### Server endpoint
288
-
- 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.
289
-
- 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.
290
-
- Failover Clustering is supported only with clustered disks, but not with Cluster Shared Volumes (CSVs).
291
-
- A server endpoint can't be nested. It can coexist on the same volume in parallel with another endpoint.
292
-
- Do not store an OS or application paging file within a server endpoint location.
293
-
294
-
### Cloud endpoint
295
-
- 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](/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.
296
-
- The storage sync service and/or storage account can be moved to a different resource group, subscription, or Azure AD tenant. After the storage sync service or storage account is moved, you need to give the Microsoft.StorageSync application access to the storage account (see [Ensure Azure File Sync has access to the storage account](file-sync-troubleshoot.md?tabs=portal1%252cportal#troubleshoot-rbac)).
297
-
298
-
> [!Note]
299
-
> When creating the cloud endpoint, the storage sync service and storage account must be in the same Azure AD tenant. Once the cloud endpoint is created, the storage sync service and storage account can be moved to different Azure AD tenants.
300
-
301
-
### Cloud tiering
302
-
- 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.
303
-
- 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.
0 commit comments