So, firstly have a quick look through this which explains virtual accounts:
TechNet: Service Accounts Step-by-Step Guide
To answer your questions:
1/ You can't list these virtual accounts in that dialog box, I'm not 100% sure of the reason, but you always need to type them in manually, in your screenshot you also have the active directory domain listed, you would never see them in here as they are local accounts.
2/ You can't add permissions on files/shares on another machine by finding these accounts, as they live only on the machine that you installed SQL server on (NVOSIB-1C in your case). These accounts though can access resources on the network, but they do so in the context of the machine account of the server.
So, an example would be you have NVOSIB-1C with SQL Server installed and NVOSIB-Filer with a share on it that you want the SQL Server account to be able to access.
What you would do in this situation is to add the machine account of the SQL server to the permissions on the file share, you can do this just by assigning the account DOMAINNAME\NVOSIB-1C$ the permissions you want and then as the virtual account accesses the network in the context of the machine it lives on, it would have permission to do so.
Obviously this limits your ability somewhat to assign permissions, as anything running on NVOSIB-1C that authenticated in the context of the server would now have access to the share, if this is a concern, you can do one of 2 things:
Use standard domain service accounts for the SQL Server services, you then need to maintain passwords etc for these, but it makes assigning permissions somewhat easier.
Set up a managed service account in AD, this has the advantage that the local accounts have in that you don't need to worry about passwords, and also the advantage that you can see and manage them centrally in AD like a normal account, the main disadvantage is that you need to have the managed service account created before you install SQL server, so in your case you would have to reinstall to take advantage of this.
I quite often have to setup MS SQL Server and wondered if anyone can
provide advice on configuring the accounts the services should run as.
IMO this has been vaguely documented by Microsoft, while they point
you in the right direction I have never been able to find any concrete
examples.
It's actually documented quite thoroughly: http://msdn.microsoft.com/en-us/library/ms143504.aspx
Is there a part of that you're not sure about?
For simple deployments\development environments it is OK to use the
virtual account defaults the installer uses: e.g. NT
SERVICE\MSSQLSERVER
This is going to depend on the environment. I, personally, hate finding a server someone setup using a local account and asking to get access to network resources some time in the future, among other issues.
For production and in domain environments it's recommended to use
either a Managed Service Account, or create a domain user account(not
an admin) for each service.
Again, depends, but generally I would agree (a counter example would be availability groups where it makes sense to use a single domain account across all instances).
Allegedly if you use a domain account at installation time the
installer will set any required permissions for you.
Unless there is a failure, etc, it will do so. I'm not sure why the "Allegedly" part.
If changing the service account on an existing install from a virtual
account to a domain account the recommendation is to use the SQL
Server configuration manager to set the new service accounts.
Allegedly this will set any required permissions for you.
When changing any of the services for SQL Server, always use SSCM. Always. Period. It will set the permissions for the new account to the basics. If before the local system account was used and unrestricted permission to everything on the system was had, I would expect something to fail permissions after the change due to tighter controlled security. That's not a SQL Server SSCM fault, that's an admin fault of not granting proper EXTRA permissions (such as accessing a network share, restricted folders, items outside of the SQL Server install purview, etc.)
I just tried changing the service account in an existing install to a
domain account and it would give me a logon failure until I granted
the account 'log on as service' permission, which contradicts the part
where the SQL Server configuration manager will set any required
permissions. (Although im not sure if a GPO may have interfered with
setting this local security policy)
Sounds like a GPO is causing an issue (IMHO). Wouldn't be the first time :)
So my question is, if you create a new domain user account for each of
the SQL Server processes what permissions should be set for each
account?
I would explicitly set any permissions outside those stated in the msdn link I have above (also given by @joeqwerty and in your OP). For example, on a "backup" folder on a network share, on a new drive added to hold new databases (where setup was already run but the drive didn't exist), etc.
But it's not clear to me if that is something I should be doing
manually for the user I create to run the service as, or whether using
the SQL config manager should automatically set these permissions.
Unless something is extremely broken with the server, these shouldn't have to be manually given.
Best Answer
The virtual accounts tied to the service sid (in this case
NT SERVICE\MSSQLSERVER
) will retain any permissions given to them. This is because they don't go away, they are still tied to the service via the service sid.When you change the account, for the example you gave, other than a few house keeping items there is nothing else given. It is very well possible to change to a domain account that does not have the proper permissions to even start the SQL Server service. Nothing is transferred.
For example, if you had an account that had full access to read and write to a directory not in the SQL Server standard locations (that are part of the install process) and changed the account, the permissions stay with that account. The new account would need to be granted those permissions in order for SQL Server to properly work with anything in that folder.
The last part of being linked to the virtual account. No, they are not linked. The virtual account and service sid will stay with whatever they had.