Tech Blog

Did you know you can also defrag local meta.edb files on a client?

Well you can:

C:\Users\%UserName%\AppData\Local\Microsoft\Windows\WorkFolders\Metadata

Move users to another Work Folders server

Load balance the Work Folders servers by moving some users to a new server.

1. Create new security groups for each Work Folders sync share
2. Migrate the existing data to the new server (see detailed steps below)
   1. There are two options:
      1. Let the Work Folders client seed the new server
      2. Pre-seed the data on the new server (move the user folder from the old server to the new server)

(Note: If this step is performed, the ACLs and timestamps must be retained or the client will re-sync all data.

3. Deploy Work Folders on new server
4. Give users access to the sync share on the new server
5. Remove access to the sync share on the old server

Detailed steps can be found in the following forum post: https://social.technet.microsoft.com/Forums/windowsserver/en-US/aef2011c-2d99-4bf8-955f-94b013d03733/howto-migrate-work-folders-server

If Work Folders is being really really rubbish then move to OneDrive.

If thats not an option then try and defrag the Database:

Defrag the Work Folders sync database

Check the size of the metadata (meta.db) on the Work Folders server. If it’s over 500GiB in size, I recommend running defrag on the database.

The meta.db is located on the same volume as the Sync Share. For example, if the Sync Share is on the D: volume, the meta.db would be located under the following path:

D:\SyncShareState\syncsharename\metadata\meta.edb

To defrag the database, perform the following steps:

Stop and disable the SyncShareSvc service (so it doesn’t start)

Run the following command from an elevated command prompt:

esentutl /d <DRIVE>:\SyncShareState\syncsharename\metadata\meta.edb

This command will defragment and compact the database.

Once the esentutl operation completes, start the SyncShareSvc service

You might of spotted that I have a few Work Folders blogs, thats because the company I work at has a lot of laptops and although not perfect Work Folders seems the best method (Outside of OneDrive) to backup documents.

We recently moved all our Work Folders servers from Server 2012 R2 to Server 2019 and since then we’ve had no end of issues with Work Folders.

Client errors such as:

Sync failed. Work Folders path: C:\Users\Joe.Blogs\Work Folders; Error: (0x80c80003) There was a problem syncing because the server is currently busy. Sync will retry later.

Just to name one.

Its odd as some users are fine and others not so the guess was the Server was just too busy to process everything.

Work Around:

One temp fix was to restart the “Windows Sync Share” service on the server.

Note, if it wont restart, kill this task: svchost.exe -k SyncShareSvcs

Potential Fix:

Things to check:

1. The user has an active sync session on another device

Or

2. The server is busy and IIS is rejecting the connections.

• Use the HTTPERR log to view if connections are rejected (log location: %windir%\System32\LogFiles\HTTPERR).
• If connections are rejected, you will see the following error in the HTTPERR log:

1. 1. 2019-09-05 19:27:34 10.1.186.194 59530 10.0.0.1 443 HTTP/1.1 GET /sync/1.0/capabilities – 503 – QueueFull SyncSharePool{FEF7C002-5430-430B-BF6F-G96EF79C24D1}

If you see the “503 – QueueFull” error in the HTTPERR log, the server cannot handle the number of connections and you need to follow the steps below to reduce the load on the server.

1. Reduce change detection frequency on the server

Work Folders has a change detection operation which runs every 5 minutes and scans the user folder for any changes that were made outside of Work Folders (e.g., users updating files through SMB). If users are not accessing\updating their files on the Work Folders server via SMB, increase the frequency in which the change detection operation runs by using the following cmdlet: Set-SyncServerSetting –MinimumChangeDetectionMins

2. Reduce client change notifications

Reduce how often clients are notified of file changes. This feature (faster change replication) was introduced in Server 2016 (more details below).

To disable the faster change replication, create the following registry setting under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SyncShareSrv\SyncCore\ChangeDetection:

Note: The SyncCore and ChangeDetection registry keys need to be created if they don’t exist.

Once you create the registry setting, you need to restart the Windows Sync Share (SyncShareSvc) service.

So more work folders, you lucky people.

After all the stuff I did in my last post, I kept getting this:

The Windows Sync Share service detected that an error occured that requires the database to be recreated. Database path: \\?\H:\userfiles\workfolders_root\Robby.De; Error code: (0x80c80209) The root directory of the sync share does not exist or could not be opened.

Basically the work folder on the server was creating itself so it wouldnt sync…..

So to fix, either:

1) Backup the users documents, then bin their profile from the computer, reboot.  Should re-create itself.

2) As the user, go to the sync share on the server and create a folder with the name of the username.

Both seem to work and if its for loads of users, you could create a logon script to create it.

New-Item -ItemType directory -path "\\Fileserver\userfiles\$env:username"

Recently set up more work folder syncs, seemed to work well then tragedy happened and it broke….well it broke for one sync share and all its users:

The Windows Sync Share service failed to setup a new sync partnership with a device. Database: \\?\H:\userfiles\SyncShareState\userfiles\Metadata; User folder name: \\?\H:\USERFILES\WORKFOLDERS\Kev.Man; Error code: (0x80070002) The system cannot find the file specified.

The disks on the server are setup as a cluster, so failed the disks to the second cluster which has worked in the past i.e. force the sync service to start again…no luck.

So next I found a reg setting that will allow Work Folders to support up to 16 Sync Shares per Work Folders server.

The default number of JET databases that can be opened simultaneously is 16 per server.

You can increase the number of JET databases by creating the EseParameterSettings registry value under the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SyncShareSvc\Settings

Value: EseParameterSettings
Type: REG_MULTI_SZ
Data:

[GLOBAL]
JET_paramMaxInstances=1024

For JET_paramMaxInstances, the maximum value is 1024.

After creating the registry value, restart the Windows Sync Share (SyncShareSvc) service.

This is where I had some more issues.  The service just said “Stopping”, so fix this looked at the service and its called “svchost.exe”:

Looking in task managed there’s loads of svchost.exe files so check what the service is running as and then end the task that is accosicated to that user:

Boom, service stopped.

Start it up again…..no luck.

So at this point I was irritated, so I renamed the sync share folder and deleted the syncshare:

Remove-SyncShare -name userfiles

After that I re-created the folder and setup the share, PAYING VERY CLOSE ATTENTION TO THE FOLDER PERMISSIONS!!!

Then created the share:

New-SyncShare -Name "userfiles" -Path "H:\userfiles\workfolders_root" -User "bohemiamgrove\Workfolders Users" -RequireEncryption $false -RequirePasswordAutoLock $false

Well it still wasnt working, so I logged on as one the users and manually created their folder in the share location and all of a sudden it started working….I’m going to test a new user shortly to see if it creates the folders itself.

All our users kept getting:

There was a problem, but sync will try again.

(0x80c80317)

On the server we kept getting the following event:

The Windows Sync Share service failed to setup a new sync partnership with a device. Database: \\?\S:\users\SyncShareState\WorkFolders\Metadata; User folder name: \\?\S:\WorkFolder\WORKFOLDERS_ROOT\USER.TEST; Error code: (0x8e5e0408) Unable to read from or write to the database.

To fix it:

• I failed the roles over and rebooted both nodes of the cluster, nothing.
• I disabled restarted the sync share through the server admin console,
• I’ve tried to rename the metadata on the client:

C:\Users\User\AppData\Local\Microsoft\Windows\WorkFolders\Metadata

• I’ve tried repairing a user which seems broken:

Repair-SyncShare -name workfolders -user Domain\test

Repair-SyncShare : (0x80c80317) There was a problem, but sync will try again.

At line:1 char:1

+ Repair-SyncShare -name WorkFolders -user Domain\test

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 + CategoryInfo: NotSpecified: 
(Msft_SyncShare (Name = "MA_Userfiles"):Root/Microsoft/.../Msft_SyncShare) [Repair-SyncShare], CimException    
+ FullyQualifiedErrorId : HRESULT 0x80c80317,Repair-SyncShare

So here’s the weird thing, I tried the following which seemed to fix it (I’ve no idea why):

Get-SyncUserStatus -User domain\test -syncshare WorkFolders

So to apply to all users (which also worked), first I gained the users from the AD group I used (I dont have the AD functions on my work folders server):

Get-ADGroupMember -Identity "Workfolders Users" | 
select SamAccountName | Export-Csv c:\temp\WorkFolders.csv

Then used the CSV to apply the Get-SyncuserStatus to all users:

$List = Import-Csv C:\temp\WorkFolders.csv
foreach ($user in $list) {
Get-SyncUserStatus -User $user.SamAccountName -syncshare WorkFolders}