Issue with CMS Replication in a Hardened Environment

This was an interesting issue I ran into recently at a customer.  They were migrating to Skype for Business Server 2015 from Lync Server 2013.  They were having issues with CMS replication to the new Skype for Business Front End Servers.  With the CMS hosted on the Lync Server 2013 Front End, none of the Skype for Business Front Ends would replicate.  We moved the CMS to the Skype for Business Front End and it was able to replicate with the Lync Server 2013 Front End and itself, but not the other Skype for Business Front End:


We knew that the issue was related to a GPO that was being pushed to the new Skype for Business servers, because when we put the servers in an OU without any GPOs, the issues went away.  After reviewing the assigned GPOs we found the setting causing the issue.  In the Local Security Policy > Local Policies > User Rights Assignment > Access this computer from the network, they had removed everything except the Administrators group:

2017_03_06_01-03 2017_03_06_01-02

This caused replication to break to the other Skype for Business servers, because Network Service wasn't able to connect to the Front Ends anymore to replicate the CMS changes.  You may or may not see any errors in the Event Log about this:


Log Name:      Lync Server
Source:        LS File Transfer Agent Service
Date:          3/6/2017 9:37:54 AM
Event ID:      1017
Task Category: (1121)
Level:         Error
Keywords:      Classic
User:          N/A
File transfer failed for some replica machines. Skype for Business Server 2015, File Transfer Agent will continuously attempt to replicate to these machines.

While this condition persists, configuration changes will not be delivered to these replica machines.
Replica file transfer failures: Access failed. (Can't watch \\\xds-replica\to-master.)
First Observed: 3/6/2017 9:29:32 AM Details: System.ComponentModel.Win32Exception (0x80004005): The specified network name is no longer available Access failed. (\\\xds-replica\from-master\
First Observed: 3/6/2017 9:30:23 AM Details: System.IO.IOException: Logon failure: the user has not been granted the requested logon type at this computer.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalDelete(String path, Boolean checkHost)
at Microsoft.Rtc.Xds.Replication.FileTransfer.FileTransferTask.CopyFiles(String fromDir, String toDir)
Dependent Machines: ALL :
Cause: Possible issues with transferring files to the replicas listed above.
Check the accessibility of file shares or https web services listed above.


Once we added the normal groups back:


Replication started working again: 2017_03_06_01-06