How to Set Up Work Folders for Data Synchronisation on Windows Server 2022

How to Set Up Work Folders for Data Synchronisation on Windows Server 2022

Work Folders is a Windows Server role service that allows users to synchronise work files to their devices, including Windows PCs and Windows tablets, without requiring a VPN or corporate network connection. It provides a central storage location on the server while replicating data to user devices automatically, enabling offline access. Unlike OneDrive for Business, Work Folders keeps data fully on-premises, which makes it suitable for organisations with strict data residency requirements or in environments where cloud storage is not permitted. This guide covers the full deployment of Work Folders on Windows Server 2022, from role installation to client configuration and monitoring.

Prerequisites

Before deploying Work Folders, ensure the following are in place. The server must be running Windows Server 2022 (or 2012 R2 or later) and be a domain member. You will need a valid TLS/SSL certificate bound to the Work Folders website in IIS—this is mandatory because Work Folders uses HTTPS for all client communication. The certificate must be trusted by client devices. You should also decide on the sync share storage location and ensure adequate disk space. Clients must run Windows 10 or Windows 11 to use the built-in Work Folders client.

Installing the Work Folders Role Service

Work Folders is a role service under the File and Storage Services role. Install it using PowerShell:

Install-WindowsFeature -Name FS-SyncShareService -IncludeManagementTools

# Verify the installation
Get-WindowsFeature -Name FS-SyncShareService

This also installs IIS components required by Work Folders. After installation, the Work Folders service (SyncShareSvc) will be running:

Get-Service -Name SyncShareSvc | Select-Object Name, Status, StartType

Binding the TLS Certificate

Work Folders requires HTTPS. You must bind a trusted certificate to the Work Folders website in IIS. If you have an internal PKI (Active Directory Certificate Services), request a certificate with the server’s FQDN as the subject. If you are using a public CA, ensure the certificate covers the FQDN clients will use to connect externally.

Import the certificate if you have a PFX file:

Import-PfxCertificate -FilePath "C:Certsworkfolders.contoso.com.pfx" `
                      -CertStoreLocation Cert:LocalMachineMy `
                      -Password (ConvertTo-SecureString -String "CertPassword123!" -AsPlainText -Force)

Get the thumbprint of the imported certificate:

Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like "*workfolders*"} | 
    Select-Object Thumbprint, Subject, NotAfter

Bind the certificate to the Work Folders IIS site using the thumbprint:

Import-Module WebAdministration

# Remove any existing HTTPS binding on port 443 for Work Folders site
# Then add the correct binding
$cert = Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like "*workfolders*"}
New-WebBinding -Name "Work Folders" -Protocol https -Port 443 -HostHeader "workfolders.contoso.com"

# Assign the certificate to the binding
$binding = Get-WebBinding -Name "Work Folders" -Protocol https
$binding.AddSslCertificate($cert.Thumbprint, "My")

Creating a Sync Share with New-SyncShare

A Sync Share is the server-side component that defines what gets synchronised and to which users. Each user gets a personal subfolder within the sync share. Create the sync share directory structure first:

New-Item -Path "D:WorkFolders" -ItemType Directory -Force

Create the sync share targeting all users in a specific security group:

New-SyncShare -Name "UserData" `
              -Path "D:WorkFolders" `
              -UserFolderName "username" `
              -User "CONTOSOWorkFolders_Users" `
              -RequireEncryption $true `
              -RequirePasswordAutoLock $false `
              -FallbackEnterpriseID "workfolders.contoso.com"

The -UserFolderName "username" parameter causes Work Folders to create a subfolder named after each user’s username (e.g., D:WorkFoldersjsmith). The -RequireEncryption $true flag forces the client device to encrypt the Work Folders data using BitLocker or the built-in Work Folders encryption. The -FallbackEnterpriseID sets the server URL clients use when they cannot discover it automatically via DNS.

Verify the sync share was created:

Get-SyncShare | Format-List *

User Folder Structure on the Server

When a user first syncs, Work Folders automatically creates a folder for that user under the sync share path. The structure looks like this:

D:WorkFolders
    jsmith          ← Created automatically on first sync
    mwilliams
    kpatel

The server applies appropriate NTFS permissions to each user’s folder automatically—each user gets full control of their own folder, and no other standard user can access another user’s folder. Administrators and the SYSTEM account retain access for backup purposes.

To pre-create user folders and set up permissions manually (useful for migrating existing data):

$users = @("jsmith", "mwilliams", "kpatel")
foreach ($user in $users) {
    $path = "D:WorkFolders$user"
    New-Item -Path $path -ItemType Directory -Force
    icacls $path /inheritance:r
    icacls $path /grant "CONTOSO$user`:(OI)(CI)F"
    icacls $path /grant "CONTOSODomain Admins:(OI)(CI)F"
    icacls $path /grant "SYSTEM:(OI)(CI)F"
}

Configuring Work Folders via Group Policy

Group Policy is the recommended way to push Work Folders settings to domain-joined Windows clients automatically, eliminating the need for users to manually enter the server URL. The relevant Group Policy settings are located under:

Computer ConfigurationAdministrative TemplatesWindows ComponentsWork Folders
User ConfigurationAdministrative TemplatesWindows ComponentsWork Folders

Key policy settings:

Policy: "Specify Work Folders settings"
Value: Enabled
Work Folders URL: https://workfolders.contoso.com
☑ Force automatic setup for all users

When “Force automatic setup” is enabled, Work Folders configures itself silently on the client without requiring user interaction. The sync starts automatically at next logon.

To configure this via Group Policy PowerShell (requires RSAT Group Policy module):

Import-Module GroupPolicy

# Create a new GPO for Work Folders
$gpo = New-GPO -Name "Work Folders Configuration"

# Link it to the OU containing client computers
New-GPLink -Name "Work Folders Configuration" -Target "OU=Workstations,DC=contoso,DC=com"

Work Folders Client Setup on Windows 10 and 11

On Windows 10 and 11, Work Folders is built into the operating system as a Control Panel applet. When Group Policy is configured, the setup is automatic. For manual setup, users navigate to Control Panel > Work Folders and enter the server URL:

https://workfolders.contoso.com

Alternatively, if the server uses the user’s email address for autodiscovery, users can enter their email address and the client will discover the Work Folders server via a DNS TXT record:

DNS TXT record: workfolders.contoso.com → https://workfolders.contoso.com

The Work Folders directory on Windows clients is created at C:Users<username>Work Folders by default. Users can choose a different location during setup.

Requiring Data Encryption on Devices

Work Folders can enforce that the client device encrypts Work Folders data. When encryption is required, Windows applies EFS (Encrypting File System) encryption to Work Folders files on the client if BitLocker is not protecting the drive. Configure this on the sync share:

# Enable encryption requirement on existing sync share
Set-SyncShare -Name "UserData" -RequireEncryption $true

# Verify
Get-SyncShare -Name "UserData" | Select-Object Name, RequireEncryption

When this policy is enforced, users who have not enabled encryption on their device will be prompted to do so before syncing can begin. If the device does not meet the encryption requirement, Work Folders will not sync to that device.

Selective Sync and User Access Control

You can restrict which users have access to a sync share and manage user access after creation. To add or remove users from an existing sync share:

# View current users/groups allowed to sync
Get-SyncShare -Name "UserData" | Select-Object -ExpandProperty User

# Add a new group to the sync share
Set-SyncShare -Name "UserData" -User @("CONTOSOWorkFolders_Users", "CONTOSOContractors")

# Check sync share user list
Get-SyncShare -Name "UserData" | Select-Object Name, User

To remove a user’s sync access and optionally delete their data:

Set-SyncShare -Name "UserData" -User @("CONTOSOWorkFolders_Users")
# Remove jsmith from the group to revoke access

Monitoring Sync Share Status

Use PowerShell cmdlets to monitor the health and activity of Work Folders sync shares:

# Get detailed information about all sync shares
Get-SyncShare | Format-List *

# Check the SyncShareSvc service status
Get-Service -Name SyncShareSvc

# View Work Folders event log
Get-WinEvent -LogName "Microsoft-Windows-SyncShare/Operational" -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message

# Check for sync errors
Get-WinEvent -LogName "Microsoft-Windows-SyncShare/Operational" |
    Where-Object {$_.Level -eq 2} |
    Select-Object TimeCreated, Message -First 20

Publishing Work Folders Externally via Web Application Proxy

For users to sync from outside the corporate network without a VPN, you can publish Work Folders through Web Application Proxy (WAP), which is the reverse proxy role in Windows Server 2022. WAP is installed on a server in the DMZ and pre-authenticates requests using AD FS before forwarding them to the internal Work Folders server.

# Install Web Application Proxy role (on the DMZ server)
Install-WindowsFeature -Name Web-Application-Proxy -IncludeManagementTools

# Configure WAP to publish Work Folders (requires AD FS configured)
Add-WebApplicationProxyApplication `
    -BackendServerUrl "https://workfolders-internal.contoso.com" `
    -ExternalCertificateThumbprint "A1B2C3D4E5F6..." `
    -ExternalUrl "https://workfolders.contoso.com/" `
    -Name "Work Folders" `
    -ExternalPreAuthentication PassThrough

Using PassThrough pre-authentication means WAP passes the connection through without requiring AD FS authentication first—Work Folders handles its own authentication via Basic Auth over HTTPS. For higher security, configure AD FS pre-authentication to require multi-factor authentication before the user reaches Work Folders.

Work Folders vs OneDrive for Business

Understanding when to use Work Folders versus OneDrive for Business helps you choose the right solution for your environment.

Work Folders keeps all data on-premises on your Windows Server infrastructure. It requires no Microsoft 365 licence and no internet connectivity for internal sync. It supports Windows 10/11 clients. Data never leaves your network unless you publish it externally. This makes it appropriate for regulated industries, government environments, or any organisation that cannot use cloud storage.

OneDrive for Business is a cloud-based solution tied to Microsoft 365. It supports Windows, macOS, iOS, and Android, offers much larger storage quotas, integrates tightly with SharePoint and Teams, and requires no on-premises server infrastructure. However, data is stored in Microsoft’s cloud datacentres, which may not meet data residency requirements in all regions.

The key decision factors are: data residency requirements, client platform diversity, Microsoft 365 licensing, and available server infrastructure. For purely on-premises Windows environments with strict data control requirements, Work Folders remains the right choice.

Summary

Work Folders on Windows Server 2022 provides a robust, on-premises file synchronisation solution that gives users offline access to their work files while keeping data under organisational control. The deployment requires careful attention to the TLS certificate configuration, sync share creation, and Group Policy configuration. With proper setup, users get a seamless sync experience on Windows 10 and 11 clients, and administrators retain full visibility and control over data through PowerShell cmdlets and the Windows event log.