Tech Blog

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

Well you can:

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:

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:

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:

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.

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 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:

Value: EseParameterSettings
Type: REG_MULTI_SZ
Data:

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:

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

Then created the share:

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:

On the server we kept getting the following event:

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:

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

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

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):

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