>>>Jeff, Dmitry,
>
>>>1) This is not correct. Services do not require any user to be logged in. They run under the System account. Rights to folders etc. can be set up as normal if needed.
>
>Ok, maybe System is not actually a traditional user, but it really is a user.
>
>IMO, it is bad practice to use System as a user account because System has complete access to the computer. Using System is a security risk.
>
>From: https://security.stackexchange.com/questions/66743/system-account-in-windows#66747
>
> The SYSTEM account is a pseudo-account similar, but not identical, to root on Linux. The two primary differences are that (a) the SYSTEM account is a service account, and therefore does not have a user profile, and (b) the Windows permissions model still enforces ACLs such that objects can exist which SYSTEM cannot directly access (though it can still grant a privilege to a token and gain access that way).
>
>The SYSTEM account is the highest privilege level in the Windows user model. It exists to provide ownership to objects that are created before a normal user logs on, such as the Local Security Authority Subsystem (LSASS) and the Session Management Subsystem (SMSS).

Yep, agree with you there. To further expand on what you're saying, using some of the built-in entities will often give you headaches some time in the future.
-- changes to how built-in users operate within system (e.g. permissions are changed when you update the OS) could result in problems.
-- "tweaking" existing policies with Policy Editor may get "undone" with an update to the OS
-- Behavior with certain built-in user identities may change -- e.g. in old versions of Windows Server the IUSER_hostname was once the user identity associated with Web site host. At some point this role was changed to use a group IUSER. If you tried to assign rights based on the old username, you might find it works for a while, then stop working after a while.
-- generally you should be using a custom username *specifically* for the use by services and components rather than an existing username. There will be occasions where people may retire or will be "let go" -- and the username they use will be deactivated. You probably don't want services to suddenly stop working because of that.
-- it's generally better to be creating a group, assigning access rights with the group, then assigning users to that group. Although it may seem "more straightforward" to assign rights on a per-user basis, it's a maintenance nightmare waiting to happen.
-- when creating usernames and groups to be used with your application, make sure you're careful in naming of them, and set up good description for them. You don't want situation where someone performing a system security audit to be removing these because they don't seem to serve a known purpose.