SYSTEM_USER in SQL Server 2016 returning different value than in SQL Server 2014 in case of Windows authentication

Question

When we run SYSTEM_USER in 2014, and 2016 we get different results.

We are running the commands running as NETWORK SERVICE.

In 2014 we receive NT Service/Network Service

In 2016 we receive a weird WORKGROUP/COMPUTERNAME$

What is going on?

Answer 1

Hello,

Which service account are used for SQL Server 2014 and for 2016? Are both running on the same Windows OS version or are they different?

---

Olaf Helper

[ Blog] [ Xing] [ MVP]

Answer 2

Yes, that is correct.

Please see "Virtual Accounts": https://msdn.microsoft.com/en-us/library/ms143504.aspx

Answer 3

Yep same OS. Windows 8.

Same account running both 2014 and 2016. Its the account SQL server creates when running setup.

Answer 4

That seems to suggest anything greater than 2008, so why the different results in 2014 and 2016?

Answer 5

During the installation, you are prompted for the service account.  The default service account in 2008+ is a "virtual account".  That does not prevent you from selecting a different account during installation or after installation.

Answer 6

During the installation, you are prompted for the service account.  The default service account in 2008+ is a "virtual account".  That does not prevent you from selecting a different account during installation or after installation.

But that has nothing to do with the question. When you use a virtual account as the service account, SYSTEM_USER also reports this account. However, if you use Network Service for whatever reason, SQL 2016 returns this WORKGROUP\MACHINE$. This is what I found when I tested.

Unfortunately, I don't know the rationale for this change, nor do I know whether it is intentional or not. ph0grove, you could try reporting it on http://connect.microsoft.com/SqlServer/Feedback, to see what response you get.

Although, if this is something that is stopping and you think that you would need a fix, you are better off opening case, as the response on a Connect request is far from always immediate.