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
esentutl /d meta.edb
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
esentutl /d meta.edb
Move users to another Work Folders server
Load balance the Work Folders servers by moving some users to a new server.
(Note: If this step is performed, the ACLs and timestamps must be retained or the client will re-sync all data.
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:
Or
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.
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
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.
Registry value | Type | Data |
UseShortPolling | REG_DWORD | 1 |
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:
C:\Users\User\AppData\Local\Microsoft\Windows\WorkFolders\Metadata
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}