<div>
thank you for that.<br />
is MSA and VSA practically the same features (except for password management thru AD or auto)<br />
<br />
this is for sql 2016.standalone workstations. they will have local instance, and then connect SSMS to other SQL Instances outside (with appropriate permissions)<br />
<br />
if this is for an image that will be distributed to many PCs on the go, do you see any issues with MSA/VSA?<br />
<br />
with VSA, do you have to restrict privilege, since it is totally AUTO
</div>


<div>
&gt;&gt;They are more or less identical, yes. Big different is that MSA is created in AD and VSA is created locally in each machine.<br />
not all users will have access to AD (to admin); so that will make VSA the easier choice?<br />
<br />
&gt;&gt;Use virtual accounts for the SQL Server service. <br />
do you mean MSA/VSA?<br />
<br />
&gt;&gt;You shouldn't need to connect to SQL Server instances with the service account.<br />
sorry for miscommunicating.. yes, service account only to run the service and SQL logins to connect to other instances.<br />
<br />
&gt;&gt;I wouldn't recommend to create images of SQL Server. <br />
thanks. i will make this recommendation to the team<br />
<br />
&gt;&gt;also you might need to remove the service account and create another one for each machine.<br />
is this true for MSA/VSA but not for build-in-accounts and Domain Acct?<br />
&nbsp;<br />
&gt;&gt;you should only use it for SQL Server service and nothing else. That way you'll guarantee maximum security since the necessary permissions will be assured and nothing more than that. <br />
this is true only for MSA/VSA, right? for BUILT-in-accounts and Domain accts, you will need to trim privileges where applicable?
</div>


<div>
thank you<br />
<br />
&gt;&gt;if somebody knows the SQL Server service credential <br />
<br />
this is true for Domain Accounts, only, right?<br />
Built-in-accounts don't have passwords <br />
and for MSA/VSA, they are AUTO pw managed?
</div>


<div>
&gt;&gt;And that's why they are recommended for the SQL Server service account. Not even the DBA or a Sysadmin knows those passwords. <br />
<br />
you are referring to MSA/VSA, here? just want to confirm
</div>


<div>
there are multiple SQL services in 2016:<br />
SQLServerInstance<br />
SQLServerAgent<br />
SQLBrowser<br />
SQLCEIP<br />
IntegrationServices13.0<br />
IntegrationServices CEIP13.0<br />
SQLVSS<br />
<br />
If you choose VSA as proper standard, then do you apply same VSA to all 7 services? or will it create 7 unique VSAs?
</div>


<div>
&gt;&gt;For each one of the other services, setup will create individual accounts for each of one of those services. <br />
<br />
do you mean it(VSA) has to be done only during setup (install) only? what if defaults or built-in accounts were used at install and you desire to change it now.. can you guide for that?
</div>


<div>
&gt;&gt;I think that VSA accounts are created only during setup<br />
VSA is the only one with this restriction, right? All the other 3 options can be implemented at anytime?<br />
<br />
could you create MSA account any time going forward (in AD)
</div>


<div>
ok, I will read on MSA there
</div>


<div>
[ Local Service, Local System , Network Service] <br />
<br />
In the link, you had mentioned Local System , Network Service for BUILT-in accounts; is there a reason &quot;Local Service&quot; is left out.<br />
~~~~~~~~~~~~~<br />
<br />
in SQL Server Agent (MSSQLServer) Property,<br />
<br />
1)<br />
There is a Log on as:<br />
Local System Account (Allow Service to interact with desktop)<br />
<br />
or<br />
&nbsp;<br />
2)<br />
This Account and Password.<br />
<br />
if it were to be chosen, how would you add &quot;Local Service&quot; or &quot;Network Service&quot; here? or would those be done at setup, too?
</div>


<div>
your link mentions this:<br />
<a href="https://blogs.msdn.microsoft.com/arvindsh/2014/02/03/managed-service-accounts-msa-and-sql-2012-practical-tips/" rel="ugc">https://blogs.msdn.microsoft.com/arvindsh/2014/02/03/managed-service-accounts-msa-and-sql-2012-practical-tips/</a><br />
<br />
{<br />
inbuilt accounts or ‘Virtual Account’ do impose the machine boundary and cause problems when you want to ‘jump’ across instances.<br />
}<br />
<br />
can you give an example of what this 'jump' across instance could mean?
</div>


<div>
A Summary So far:<br />

<ul>
<li>unique account preferable for each service</li>
<li>MSA- needs AD.. (little out of scope due to AD permission issues..)</li>
<li>VSA- good, but needs to be done at install</li>
<li>Domain Accounts- Not needful for developer workstations</li>
<li>built-in account (Local System) - OK, but VSA is better for developer workstations.</li>
</ul>
<br />
in the above light, for already existing developer workstation SQL 2016 installs, would you say (Local System) is best choice, since VSA was not chosen at install?
</div>


<div>
&gt;&gt;Sure. Since VSA works only locally<br />
you mean the VSA account is not a SQL Login, in plain words, right?
</div>


<div>
&gt;&gt;No. Not OK at all. It has a lot of security issues. Only use it for SQL Browser and VSS. <br />
<br />
so you would recommend total reinstall then? (unless you find VSA can be still used on the fly?)<br />
(programmer has to be willing to tolerate this reinstall process for any disruption.. if that is the only way out)<br />
<br />
~~~<br />
I checked a developer machine:<br />
<br />
this is what is there for sql 2016 in that box, and there are a quiet a few developers who would have that way, as below:<br />
<br />
SQLServer &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LocalSystem<br />
Agent &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LocalSystem<br />
VSS &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;LocalSystem<br />
Browser &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;Local Service&quot;<br />
IS 13.0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Network Service.
</div>


Default-Service-accounts.PNG

<div>
thanks Vitor.. let me try it..<br />
<br />
on the image question, it is not best standard.. but if you take this as image and build another PC, will sql server fail to start (according to your find &quot;<b>you have to type the name in yourself</b> &quot;)? any way to correct it? (if that is the only option)<br />
<br />
<i>(as it stands it may be too late from a management perspective to change direction for this deployment.. so yes, the new PCs built will change their instance names manually.. but as per this better standard suggested by you, we will plan accordingly for future deployments giving time for all to adapt)</i><br />
<br />
on your chart, what is the service account for VSS? (I know you said &quot;SQLBrowser and SQLVSS uses local system&quot;, but interested to know if VSA Acct took over SQLVSS also, like for browser[NTAuthority/LocalS<wbr />ervice])
</div>


SQLServer-services.PNG

<div>
1)<br />
thank you for checking with defaults. just to confirm i understood you right, you recommend that Microsoft default happens to be the best standard (for service accounts) for SQL 2016 on Win10, right? <br />
<br />
2)<br />
it will be different on windows OS 2016 with domain accounts preferred, right?<br />
<br />
3)<br />
your link had this quote:<br />
&gt;&gt;there’s no need to access network resources then Virtual Accounts are best for new builds. <br />
Can you give examples of 'Access Network Resource' situation for SQL Server?<br />
is it something like this: (going across network).. <br />
RESTORE DATABASE [HiDatabase] FROM &nbsp;DISK = '\\SomeBox\D$\DatabaseBack<wbr />up.bak' WITH REPLACE, STATS = 100<br />
if this is it, then, can you also share any other examples of &nbsp;'Access Network Resource' situation for SQL Server, so we can fully know what cant be done with VSA on workstation<br />
<br />
4)<br />
you linked for ps: <a href="http://www.robwatkins.me.uk/2015/03/configuring-sql-server-to-use-managed-service-accounts-in-powershell/" rel="ugc">http://www.robwatkins.me.uk/2015/03/configuring-sql-server-to-use-managed-service-accounts-in-powershell/</a><br />
but that does not refer VSA, only MSA, right?
</div>


<div>
&gt;&gt;There's nothing to do with OS. Meaning that in Win10 or Win2016 the default accounts will apply the same way.<br />
but you wont recommend non-domain accounts for Server OS SQL Box, would you?
</div>


<div>
thanks for confirming for OS2016 service accts for SQL Server
</div>


<div>
based on your chart in 42059259, can you modify the parameters, so I can follow how it should be done: thanks.<br />
(and then run the code separate for SQLServer, SQLServerAgent, IS130, browser, VSS?<br />
<br />

<pre><code class="code-10 nolinks" id="code-20-42059368-1"><span>    </span>
<span>#&gt;</span>
<span># AD Domain Name</span>
<span>$DomainName = &quot;VitorsDomain&quot;</span>
<span> </span>
<span># Name of VSA to create</span>
<span>$VSAccountName = &quot;NTService\MSSQLSERVER&quot;</span>
<span> </span>
<span>#Hostname of server running the SQL Instance</span>
<span>$SQLServerName = &quot;Vitor-PC&quot;</span>
<span> </span>
<span>#SQL Instance Name to reconfigure to use the VSA</span>
<span>$SQLInstanceName = &quot;MSSQLSERVER&quot;</span>
<span> </span>
<span> </span>
<span>#If not installed add the PowerShell AD features</span>
<span>if ((Get-WindowsFeature RSAT-AD-PowerShell).InstallState -ne 'Installed') {</span>
<span>	Add-WindowsFeature RSAT-AD-PowerShell</span>
<span>}</span>
<span> </span>
<span> </span>
<span>#Create the VSA for the SQL Service</span>
<span>New-ADServiceAccount -Name $VSAccountName -Enabled $true -RestrictToSingleComputer</span>
<span> </span>
<span>#Add the newly-created VSA to the server running SQL Server</span>
<span>Add-ADComputerServiceAccount -Identity $SQLServerName -ServiceAccount $VSAccountName</span>
<span> </span>
<span>#Install the VSA on this local server - configures the local server to manage the password itself</span>
<span>Install-ADServiceAccount $VSAccountName</span>
<span> </span>
<span>#Reconfigure SQL Server to use the new VSA</span>
<span>[System.Reflection.Assembly]::LoadWithPartialName(&quot;Microsoft.SqlServer.SqlWmiManagement&quot;) | out-null</span>
<span> </span>
<span>$SMOWmiserver = New-Object ('Microsoft.SqlServer.Management.Smo.Wmi.ManagedComputer') &quot;localhost&quot;           </span>
<span> </span>
<span>$ChangeService=$SMOWmiserver.Services | where {$_.name -eq $SQLInstanceName}</span>
<span> </span>
<span>$UName=&quot;$DomainName\$VSAccountName$&quot;</span>
<span>$PWord=&quot;&quot;           </span>
<span> </span>
<span>$ChangeService.SetServiceAccount($UName, $PWord)</span>
</code></pre>
</div>


<div>
thank you; i'll code that example and then create for AGENT,IS130
</div>


<div>
can you confirm:<br />
(below both have in common)<br />
Built-in Accounts - privileges can’t be customized<br />
virtual account &nbsp;- privileges can’t be customized
</div>


<div>
a VSA-SQL question (if you'd have time to address that, I'd appreciate it as I did not want to load more into this question, already it has been long thread and I thank you)<br />
<a href="https://www.experts-exchange.com/questions/29010856/what-is-SQL-Server-that-has-centralized-access-control-for-the-service-account-they-run-under.html" rel="ugc">https://www.experts-exchange.com/questions/29010856/what-is-SQL-Server-that-has-centralized-access-control-for-the-service-account-they-run-under.html</a>
</div>


<div>
one last question (after 42059393 ) in this post, please:<br />
<br />
in the link you shared <br />
<a href="http://www.robwatkins.me.uk/2015/03/configuring-sql-server-to-use-managed-service-accounts-in-powershell/" rel="ugc">http://www.robwatkins.me.uk/2015/03/configuring-sql-server-to-use-managed-service-accounts-in-powershell/</a><br />
it refers to &quot;Local Account&quot; as one of the 5 options. Can you suggest why do not recommend it?
</div>


<div>
&gt;&gt;What do you consider Built-in-Accounts? <br />
as per<br />
<a href="http://www.robwatkins.me.uk/2015/03/configuring-sql-server-to-use-managed-service-accounts-in-powershell/" rel="ugc">http://www.robwatkins.me.uk/2015/03/configuring-sql-server-to-use-managed-service-accounts-in-powershell/</a><br />
<br />
[◾Built-in Account – The Local Service, Network Service or Local System accounts]
</div>


<div>
Ah, those ones? As far as I know you can't customize them. The same for VSAs.
</div>


<div>
&gt;&gt;Ah, those ones? As far as I know you can't customize them. The same for VSAs. <br />
still you'd say [LocalSystem] can be little too much permission, (cant be customized any bit or permissions brought down or downgraded) yet<br />
VSAs are 100% perfect permissions for SQL Server local instance for developer workstation, but again cant be cant be customized any bit?<br />
can you confirm i understood you right
</div>


<div>
another related question, and did not want to add more here, after the question in 42059393 &amp;&nbsp;42059409<br />
<br />
<a href="https://www.experts-exchange.com/questions/29010859/SQL-Server-2016-Win10-Developers-all-running-built-in-service-accounts-for-SQL-Server-service-on-workstations-security-concern.html" rel="ugc">https://www.experts-exchange.com/questions/29010859/SQL-Server-2016-Win10-Developers-all-running-built-in-service-accounts-for-SQL-Server-service-on-workstations-security-concern.html</a>
</div>


<div>
<blockquote>
still you'd say [LocalSystem] can be little too much permission
</blockquote>
That doesn't mean it can be customized. The default permissions that it has are more than what SQL Server service needs. And also, LocalSystem is used by many services (you can confirm that by checking in the computer Services how many are using LocalSystem) meaning that any of those services can access easily to a SQL Server instance that runs under LocalSystem account. Using a VSA only for MSSQL service it will avoid this security issue.
</div>


<div>
thanks for your input. highly appreciated.<br />
can you address the last point: 42059409; then this post is wrapped up;
</div>


<div>
Local Account is an account that you'll need to create locally, give the necessary permissions and manage the password. Why do all these if you can use VSA instead without need to performing any task?
</div>


<div>
<div class="content wysiwyg-content">
in <br />
<a href="http://www.sqlcoffee.com/SQLServer2016_0001.htm" rel="ugc">http://www.sqlcoffee.com/SQLServer2016_0001.htm</a><br />
&quot;<br />
On the following screen you need to provide the service accounts that SQL Server services will use. As you can notice, SQL Server setup provides virtual accounts by default, they are auto-managed, they can access the network on a domain environment by using the credentials of the computer account.<br />
<br />
&nbsp;However, I still recommend to create a local user or use a domain user account to start SQLServer services.<br />
<br />
Microsoft recommends you to specify an individual account for each service.<br />
&quot;<br />
<br />
I was not able to find yet exact MSDN article that would suggest &quot;Microsoft recommends you to specify an individual account for each service.&quot;... <br />
<br />
what standard do you recommend/practice in this, and do you see any proc/cons either way..<br />
<br />
this is for a local workstation on a domain, dedicated to sql2016 to connect local instance and across network.<br />
<br />
the service is going to the same: SQLSERVER and SQLSERVERAGENT<br />
the question is about the best or correct standard going about creating the ServiceAccount.<br />
<br />
the sql2016 install will be done on an disk, image made and then that image will be put on 10 other PCs. (so that 11 SQL installs don't have to happen)
</div>
</div>


in 
http://www.sqlcoffee.com/SQLServer2016_0001.htm
"
On the following screen you need to provide the service accounts that SQL Server services will use. As you can notice, SQL Server setup provides virtual accounts by default, they are auto-managed, they can access the network on a domain environment by using the credentials of the computer account.

 However, I still recommend to create a local user or use a domain user account to start SQLServer services.

Microsoft recommends you to specify an individual account for each service.
"

I was not able to find yet exact MSDN article that would suggest "Microsoft recommends you to specify an individual account for each service."... 

what standard do you recommend/practice in this, and do you see any proc/cons either way..

this is for a local workstation on a domain, dedicated to sql2016 to connect local instance and across network.

the service is going to the same: SQLSERVER and SQLSERVERAGENT
the question is about the best or correct standard going about creating the ServiceAccount.

the sql2016 install will be done on an disk, image made and then that image will be put on 10 other PCs. (so that 11 SQL installs don't have to happen)

sql2016-WIn10: standard,for SQL servc-account..

Microsoft SQL Server 2008 is a suite of relational database management system (RDBMS) products providing multi-user database access functionality.Component services include integration (SSIS), reporting (SSRS), analysis (SSAS), data quality, master data, T-SQL and performance tuning. Major improvements include the  Always On technologies and support for unstructured data types.