Here are the steps that I used to get the Work Folders role working on Windows Server 2012 R2 Essentials. This post will not cover the Essentials setup of the server; it assumes that you already did that. In addition, there are many other blog posts about using Work Folders, but not all of them fit every situation. This post will not be able to cover every option, but I wanted to share what worked for me.
For this example I will use a hypothetical server called THESHIRE and a domain called THEONERING.LOCAL. I used the Microsoft provided .remotewebaccess.com service for the "Essentials" part of the server. If this were a real server I would use something like theonering.remotewebaccess.com as my remote site.
First of all I added the Work Folders role to the server, but did not set up a Work Folders instance. Then I made sure that the Windows Sync Share Service was stopped. (Find this under Computer Management, Services and Applications, Services.)
Work Folders uses the same ports (80 and 443) as Windows Server Essentials, which causes a conflict if you try to run both roles at the same time. In order to fix this I edited the SyncShareSvc.config (C:\Windows\System32\SyncShareSvc.config) file in notepad so that work folders would use https port 1443 instead of 443. I left the http port at 80. Find the part of the file that says Binding Protocol and Binding Information. You should see the default port 443. Just change it to a different port such as 1443 and save the file. (Editing the file requires changing file to administrators ownership, and then granting administrators full access to the file. I ran notepad as Administrator just to be safe. Also make sure that you change notepad to save as all documents and not .txt files, otherwise you will get SyncShareSvc.config.txt.)
The Sync Share Service doesn't have the rights to use the new port so I gave it the proper authority with the command: Netsh http add urlacl url=https://*:1443/ user="NT Authority\LOCAL SERVICE" (PowerShell with admin)
I created a firewall rule to allow the new port using the command: netsh firewall add portopening protocol=tcp port=1443 name="Windows Sync Share Custom Port" scope=all (PowerShell with admin) (also this command says that it is depreciated and offers a more up to date wording)
In order to get the proper SSL certificate applied to the service, I ran this PowerShell command to see what my security certificates were: Get-childitem –Path cert:\LocalMachine\My
The results look something like this(modified for privacy of course). I used the second one that says servername.domain.local.
Thumbprint Subject
---------- -------
DBD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CN=THESHIRE
8018BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CN=TheShire.TheOneRing.local
7A9CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CN=TheOneRing-THESHIRE-CA
4BA6DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD CN=theonering.remotewebaccess.com, OU=Domain Control Validated
Then I ran this command prompt with admin to bind the SSL certificate.
netsh http add sslcert ipport=0.0.0.0:1443 certhash=8018BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=My
As you can see I used the Thumbprint from the second result which is the CN=TheShire.TheOneRing.local
Next, I used the Wizard to Create a New Sync Share for Work Folders. I choose to use user alias and NOT useralias@domain. Not sure how much that matters. Most of the other settings are likely just your preferences.
On a Windows 8.1 client I navigated to control panel, system and security, work folders. Then I chose "Enter a Work Folders URL instead." I entered https://theshire.theonering.local:1443. The ":1443" is important because if you don't specify the port, it will assume you want to use the default port 443.
After that I was all set up and work folders syncs both on my local network and when I use the Windows Server Essentials VPN.
I hope this helps someone and feel free to leave comments.
For this example I will use a hypothetical server called THESHIRE and a domain called THEONERING.LOCAL. I used the Microsoft provided .remotewebaccess.com service for the "Essentials" part of the server. If this were a real server I would use something like theonering.remotewebaccess.com as my remote site.
First of all I added the Work Folders role to the server, but did not set up a Work Folders instance. Then I made sure that the Windows Sync Share Service was stopped. (Find this under Computer Management, Services and Applications, Services.)
Work Folders uses the same ports (80 and 443) as Windows Server Essentials, which causes a conflict if you try to run both roles at the same time. In order to fix this I edited the SyncShareSvc.config (C:\Windows\System32\SyncShareSvc.config) file in notepad so that work folders would use https port 1443 instead of 443. I left the http port at 80. Find the part of the file that says Binding Protocol and Binding Information. You should see the default port 443. Just change it to a different port such as 1443 and save the file. (Editing the file requires changing file to administrators ownership, and then granting administrators full access to the file. I ran notepad as Administrator just to be safe. Also make sure that you change notepad to save as all documents and not .txt files, otherwise you will get SyncShareSvc.config.txt.)
The Sync Share Service doesn't have the rights to use the new port so I gave it the proper authority with the command: Netsh http add urlacl url=https://*:1443/ user="NT Authority\LOCAL SERVICE" (PowerShell with admin)
I created a firewall rule to allow the new port using the command: netsh firewall add portopening protocol=tcp port=1443 name="Windows Sync Share Custom Port" scope=all (PowerShell with admin) (also this command says that it is depreciated and offers a more up to date wording)
In order to get the proper SSL certificate applied to the service, I ran this PowerShell command to see what my security certificates were: Get-childitem –Path cert:\LocalMachine\My
The results look something like this(modified for privacy of course). I used the second one that says servername.domain.local.
Thumbprint Subject
---------- -------
DBD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CN=THESHIRE
8018BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CN=TheShire.TheOneRing.local
7A9CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CN=TheOneRing-THESHIRE-CA
4BA6DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD CN=theonering.remotewebaccess.com, OU=Domain Control Validated
Then I ran this command prompt with admin to bind the SSL certificate.
netsh http add sslcert ipport=0.0.0.0:1443 certhash=8018BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=My
As you can see I used the Thumbprint from the second result which is the CN=TheShire.TheOneRing.local
Next, I used the Wizard to Create a New Sync Share for Work Folders. I choose to use user alias and NOT useralias@domain. Not sure how much that matters. Most of the other settings are likely just your preferences.
On a Windows 8.1 client I navigated to control panel, system and security, work folders. Then I chose "Enter a Work Folders URL instead." I entered https://theshire.theonering.local:1443. The ":1443" is important because if you don't specify the port, it will assume you want to use the default port 443.
After that I was all set up and work folders syncs both on my local network and when I use the Windows Server Essentials VPN.
I hope this helps someone and feel free to leave comments.
I'm glad you got this working. I attempted to get server folders configured and working on my essentials server a few months ago, and was unsuccessful (probably due to the workfolders/essentials conflicts). After reading your entry, I may give it another try.
ReplyDeleteOne question: The reason I was attempting to get Work Folders setup is to have a situation where there exists a shared folder on the server that both my wife and I can access from our desktops. The important part is that the folder on our desktops cannot be tagged as any type of "network" folder. The reason this is important is because I have some receipt/document scanning software that does not allow the data file to reside on the network. Due to this, it prevents me from specifying locations such as mapped drive, symlink folder, etc. since all of those somehow identify themselves as network folders to the software.
It sounds like Work Folders creates a standard folder on the client machines which performs a sync on certain time intervals, which may be a way around this software limitation. I was hoping to find out before going through the trouble of trying to get work folders configured again
I am very certain that you are correct; the Work Folders are on the local disk and the synced with the server, but they are not a traditional network share. You can access your Work Folders even if the server is offline. It is almost like and on premise OneDrive or Dropbox.
ReplyDeleteThanks, I decided to give this another try, following your steps. I noticed my configured work folders kept dissapearing (not the physical folders, just the configuration of them). Then I noticed the SyncShareSvc would be stopped anytime I rebooted. Trying to restart it would just give me an "Access is Denied" error. If I stopped the 'World Wide Web Publishing Service' I would be able to start SyncShareSrv. Though, even after the service was started, it'd still timeout trying to setup the work folders on the clients
ReplyDeleteSo after re-installing server essentials, I got this setup and working. Unfortunately, it looks like it stores each users files separately... so you can't setup a shared work folder.
ReplyDeleteI am glad you got this working. I believe that the work folders account is not tied to the local user account of the Windows machine. Therefore, couldn't you create a generic shared work folders account and enter it on each of your windows machines. You and your wife could still login to your individual machines with your regular Windows account, but work folders would sync the shared account in the background.
ReplyDeletenice Job this would also happen on a RD gateway server or any other SSL 443 port useage.
ReplyDelete