I have started to investigate the security rights of all those files, which could not be copied. All of them were inaccessible by the Administrators!
So I have changed the ownership of those files to administrators and gave the permission to them and everyone. After this step I could log in and both the folders and registry keys were created.
When I have started with this text I didn't know the solution so I have decided to keep writing and share. I did not know why suddenly the problem occured so I cannot trace it back to prevent it happening again.
Applies to:
Windows 7, 8/8.1, Windows 10 -- Home and Professional.
Programs, (like BTSync), which install services -- but don't follow Windows service conventions as other programs do, (IIS, MySQL, SQL Server, etc).
Issues:
- Software Defect: Some installations, (like BitTorrent Sync), will not install the Windows Service -- unless a regular user account is specified.
- Expected Behavior: Should automatically provide the correct NT Service account identity, or at least allow the user too.
- Security Issue: The user is forced to create another regular user account, [which as a best practice, should never be done].
- Workaround: After the Appropriate Service Account is specified, this temporary user account should be deleted.
References
Windows does not use "Service Accounts" -- in the Linux sense, but rather "Virtual Accounts" and "Managed Service Accounts, (for machines participating in an LDAP environment.
Service Account Naming Convention: By Naming Convention, it appears that the virtual accounts should follow the form, "Command Name" - [Extension] + "svc"
Note from comments: NT Service\ should be Service name from Properties > General tab - it doesn't have to contain "svc" or command name. (Though, I have not tested this with the PowerShell script.)
"btsync.exe" becomes "NT Service\btsyncsvc"
Creating the Virtual "NT Service" Account:
Open up the Local Services snap-in, "services.msc"
Navigate to the desired service, (btsync), right-click "Properties".
Select the "Log On" tab.
Select the option to specify a user.
Enter the "Conventional" service name, described above: (without quotes).
NT Service\btsyncsvc
REMOVE the passwords.
Save - Apply
Restart the Service.
Setting Folder Permissions:
Set folder permissions -- using the full account name: "NT Service\btsyncsvc", (using quotes may or may not be required depending on the context ...) ...
It is not necessary for the btsyncsvc to have execute permissions, so remove if you like -- otherwise, full control.
Error - Service Fails to Start due to "No Mapping Between Account Names and Security IDs":
For example, this error will occur if you specify, "NT Service\btsync" rather than "NT Service\btsyncsvc" ...
The following command will return the list of current service account names.
Using PowerShell, (PS), Verify the list against the one you have specified to use for "Log On":
PS > get-service | foreach {Write-Host NT Service\$($_.Name)}
Error - Service Fails to Start because the Account has not been Granted Log On as a Service Permissions:
This error can occur if you have specified the incorrect "Conventional Name", or if the permissions really are missing -- though will be automatically assigned if the correct convention is used.
In Windows 10 Home, the User will not be able to use the local security policy snap-in to configure this, (secpol.msc) -- and must be done manually, through PowerShell, or other utility.
PowerShell Scripts:
To fix this, it is possible to use PowerShell. "Grant-Log-on-as-a-service PowerShell Script, from Technet Gallery":
If PowerShell reports an "ExecutionPolicy Error", it may be necessary to change the ExecutionPolicy:
PS > Set-ExecutionPolicy RemoteSigned
... May Result in a signing error -- And then changed to:
PS > Set-ExecutionPolicy Unrestricted
And then use the Script to assign the permission:
PS > .".\Add Account To LogonAsService.ps1" "NT Service\btsyncsvc"
Reset the ExecutionPolicy if desired:
PS > Set-ExecutionPolicy Restricted
Hope this Helps!
Best Answer
Another option would be to use virtual accounts. New to Windows 7 and Windows Server 2008 R2, services can run as a virtual service account that doesn't exist as a user on the machine and cannot be used interactively.
To run a service using a virtual account, the logon user should be set to "
NT SERVICE\{servicename}" (the password can be left blank). For example, SQL Server Express' virtual account might be called "NT SERVICE\MSSQL$SQLEXPRESS"This would give two benefits:
If a service accesses the network while running as a virtual account, it accesses resources as the computer account (
DOMAIN\Computername$). But, since these computers aren't joined to a domain, this shouldn't be an issue anyway.I learned of virtual accounts from this blog post that gives a quick overview of virtual accounts (and managed service accounts).