First thing to check is the logs
Get into CLI of the callmanager (ssh) and check the files list:
file list activelog cm/trace/dirsync/log4j
then view the latest (by date) log file:
file view activelog cm/trace/dirsync/log4j/
Should the error be clear for verification and guide you in the right direction

Issue:
Remote Desktop connections fails to host after configuring RemoteDesktopCertificate template in your internal CA
You’ll have an error in the event log of the target machine like this:

The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205

Most likely this is a Windows 8, 8.1, 2012, or 2012R2

If that is the case, you’ll have to delete the certificate from the system (the one issued for RDP template) and make sure it will NOT generate new one using the same template.

Then restart the machine (or you may try to restart Remote Desktop services only) and you should be able to login again.

If you’re looking for the reason behind it, then you’ll need to read more about the SHA algorithm and the updates pushed into Windows OS in latest versions.

I’d suggest you check this blog which has a nice topic about this subject: http://www.dotnetnoob.com/2013/10/hardening-windows-server-20082012-and.html

HTH

Doesn’t really matter what feature you’re trying to enable, or which Windows OS you’re working on.
This error is common for those who have no Internet access, or slow connection and the offline (/source) key needed.
If you try to use the PowerShell to perform the same operation you’ll get a line in the log similar to this:
FIOReadFileIntoBuffer:(1415): The filename, directory name, or volume label syntax is incorrect

If you got such a thing, then most likely you have a file corruption on the disk. So try the following steps:

1. chkdsk /r
2. SFC /scannow

These commands will scan the disk and the system protected files. Then run the following for Dism cleaning:

1. Dism /Online /Cleanup-Image /StartComponentCleanup
2. Dism /Online /Cleanup-Image /RestoreHealth

After that you should be able to re-run the enablefeature command again without issues.

UPDATE: you may check article as it helped in other situation http://www.falconitservices.com/support/KB/Lists/Posts/Post.aspx?ID=101

HTH

You may get into situation where you’re unable to access (or even see) the files you want to access. Although you have administrative permissions, and you can see the files from within the application Window (in my case this happened with PuTTY). When you click browse from inside the application you can actually see the files are there and there is a lock at the corner of the file icon.

When you right-click the file, select properties and go to security tab, you’ll only be able to see the ACL. But no mater what you do, you will not be able to see the owner or modify the ACL entries, although your account has been granted the full control in the ACL.

The Windows (at least version 7 I’m using) have a nice feature that causes this confusion. The original root of the issue is the UAC feature, which prevent the account from writing inside the program folder even of the user has admin level. In the above case and in order for Windows to not prevent the working process or give an error, it simply create all files in a shadow location. Something like the file pointers in Linux OS.

Browse to (%systemdrive%\Users\%username%\AppData\Local\VirtualStore\%programfiles%\%applicationfolder%)  and you’ll find the file located there.

HTH someone