blocks|key|222061|text|当(“以系统身份运行”)工作时，人们应该被告知，这意味着从一个最低权限类型的帐户变成一个拥有世界上所有权限的帐户。这在很大程度上不是推荐的设置、最佳实践或安全方面的做法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|222062|如果您知道自己在做什么，并且知道SQL+Server将始终在隔离的环境中运行(即不在酒店或机场wifi上运行)，这可能没有问题，但这会创建一个非常真实的攻击载体，如果在开放的互联网上，它可能会完全危害机器。|222063|这似乎是微软的一个错误，人们应该意识到所发布的变通方法的影响。|222064|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.

If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.

This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.

blocks|key|2872375|text|这个问题的答案可能与完全成熟的SQL+Server+(NTService\MSSQLSERVER)的问题相同，这就是重置密码。具有讽刺意味的是，没有密码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2872376|步骤如下：|2872377|2872378|在服务mmc|unordered-list-item|2872379|中右键单击服务在登录选项卡上单击|2872380|密码字段中将显示条目...|2872381|清除两个密码字段|2872382|单击“OK”|2872383|F213|2872384|这应该会重新授予对该服务的访问权限，并且它应该会再次启动。奇怪吗？|2872385|注意:如果问题在几个小时或几天后再次出现，那么您可能有一个组策略正在覆盖您的设置，并且它会再次出现并取消设置。|2872386|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|G|7|14|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|15|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|16|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|17|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|W|$]]

The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.

Steps are:

<ul>
<li>Right click on the Service in the Services mmc</li>
<li>Click Properties</li>
<li>Click on the Log On tab</li>
<li>The password fields will appear to have entries in them...</li>
<li>Blank out both Password fields</li>
<li>Click "OK"</li>
</ul>

This should re-grant access to the service and it should start up again. Weird?

NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.

blocks|key|3086202|text|这事发生在我身上。域上的策略正在取消SQL+Server用户帐户的“作为服务登录”权限。您可以使用JLo的解决方案来解决这个问题，但没有专门解决组策略问题，下次在机器上刷新组策略时，它将返回。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3086203|导致我遇到此问题的特定策略是:在计算机配置->窗口设置->安全设置->本地策略->用户权限分配:作为服务登录|3086204|通过从命令行运行命令"rsop“，您可以查看哪些策略正在应用于您的计算机。按照上面列出的策略的路径，您将看到其当前值以及设置该值的GPO。|3086205|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.

The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service

You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.

blocks|key|2872453|text|一种可能是在安装sql+server数据工具时已经设置了sql+server。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2872454|解决方案：-1.只需使用设置好的实例修复sql+server|2872455|如果解决方案不起作用，那么值得您花时间去干预services.msc|2872456|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

One possibility is when installed sql server data tools Bi,
while sql server was already set up.

Solution:-
1.Just Repair the sql server with the set up instance 

if solution does not work ,
than its worth your time meddling with services.msc

blocks|key|224014|text|我有一个类似的问题，已经通过以下方法解决了：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|224015|224016|在Services.MSC中单击登录选项卡，然后通过启动Sql+|ordered-list-item|224017|以管理员身份运行|224018|，添加具有最低权限和密码的用户(在引发登录错误的服务上)|224019|如果用户是域用户，请使用域用户名和密码|224020|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I had a similar issue that was resolved with the following:

<ol>
<li>In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)</li>
<li>By Starting Sql Server to run as Administrator</li>
</ol>

If the user is a domain user use Domain username and password

blocks|key|224048|text|简短的回答：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|224049|在SQL+Server上安装远程服务器管理工具(这是Windows+Server的一个可选功能)，重新启动，然后运行SQL+Server配置管理器，访问登录帐户以"NT+Service...“开头的每个服务的服务设置，清除密码字段，然后重新启动服务。在幕后，SQL+Server配置管理器将为这些虚拟帐户分配“作为服务登录”权限，您就可以上路了。|224050|tl;dr；|224051|Windows域的默认设置与SQL+Server+2012的默认安装之间存在矛盾。|224052|如上所述，默认的Windows域设置确实会阻止您通过本地计算机上的组策略编辑(至少通过图形用户界面；如果您安装Powershell+ActiveDirectory模块(通过远程服务器管理工具下载))定义“作为服务登录”。|224053|默认情况下，SQL+Server+2012安装程序在“虚拟帐户”(NT服务\前缀，例如NT服务\MSSQLServer)中运行服务。这些帐户类似于本地计算机帐户，而不是域帐户，但如果您的服务器已加入域，则仍无法为其分配作为服务登录的权限。SQL+Server安装程序尝试在安装时分配权限，SQL+Server配置管理工具同样尝试在您更改登录帐户时分配权限。|224054|最妙的是:+SQL+Server工具依赖于RSAT+(的一些组件)来分配“作为服务登录”的权限。如果您的成员服务器上没有安装RSAT，SQL+server+Config+Manager将以静默方式尝试应用该设置(尽管它运行了所有华而不实的安装前验证)，并且您最终得到的服务将无法启动。|224055|我在SQL+Server和虚拟帐户文档的暴雪中找到的关于这一要求的一个提示是：https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts，搜索RSAT。|offset|length|224056|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts^0|0|0|0|0|0|0|0|13|1V|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|16|8|@]|9|@$P|17|Q|18|1|19]]|A|$]]|$1|R|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

Short answer: 
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.

tl;dr; 

There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.

As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.

And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.

And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.

The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: <a href="https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts" rel="nofollow">https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts</a>, search for RSAT.

blocks|key|3086348|text|我不知道这是一个多好的解决方案，但在遵循了这个问题的一些其他答案但没有成功后，我决定将服务MSSQLSERVER的连接用户设置为“本地服务”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3086349|注:我正在使用SQL+Server+2017。|3086350|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to &quot;Local Service&quot;.
N.B: i'm using SQL Server 2017.

I recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:

<blockquote>
 Error 1069: The service did not start due to a logon failure.
</blockquote>

The following user is configured to start the service: <code>NT Service\MSSQL$SQLEXPRESS</code>

How can I fix this problem?

SQL Server 2012 can't start because of a login failure

Windows Server

SQL Server

服务器

Windows

我最近在全新安装的Windows 7上安装了Microsoft SQL server 2012，但每当我想要运行服务器时，都会收到以下错误：错误1069:由于登录失败，服务未启动。以下用户被配置为启动服务：NT Service\MSSQL$SQLEXPRESS我如何解决这个问题？

问由于登录失败，SQL Server 2012无法启动
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问由于登录失败，SQL Server 2012无法启动EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问由于登录失败，SQL Server 2012无法启动
EN