none
KB2760411, KB2760588 but now "CANNOT CONNECT TO" SQL Server!!!

    질문

  • Today, I've been coping with the same Windows Update problems as many people -- with KB2760411 and KB2760588 endlessly reinstalling -- and attempting to resolve that included multiple system restarts --
         ((((a example link to THAT issue is here:  http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_update/updates-trying-to-install-over-and-over-again/2a624908-f4b1-46d8-87ed-caa09674ff4f?page=8&tm=1378919114747 ))))

    BUT NOW........ a serious problem on one of those machines:  cannot access SQL Server!
    Luckily, I have not run these updates on any *production* machines (I do updates on development machines, first) -- this is a development machine -- but I still need to get this machine's SQL Server working!

    I've tried using a Windows login to connect, and tried using a SQL Server user to connect, and either way, looks like the same message: 
    "Cannot connect to <servername>."
    A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 2)


    Note that, for windows, this server is running Server 2003,
    and for sql server, it's running SQL Server 2005.

    HELP???!

    ALSO NOTE:  I KNOW THIS IS NOT A "NETWORK-RELATED" ERROR,
    because I get the same message when I remote desktop into the server, and try it there.
    I did try looking in the windows event viewer for Server 2003, but saw nothing pertinent under Application, System, or Security.

    When I attempted it with a sql server login, I clicked "Show technical details", and got the below (blank lines removed, and the servername replaced with <servername>): 


    ===================================
    Cannot connect to <servername>.
    ===================================
    A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (.Net SqlClient Data Provider)
    ------------------------------
    For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=2&LinkId=20476
    ------------------------------
    Error Number: 2
    Severity: 20
    State: 0
    ------------------------------
    Program Location:
       at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject)
       at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
       at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
       at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
       at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
       at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
       at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
       at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
       at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
       at System.Data.SqlClient.SqlConnection.Open()
       at Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ObjectExplorer.ValidateConnection(UIConnectionInfo ci, IServerType server)
       at Microsoft.SqlServer.Management.UI.ConnectionDlg.Connector.ConnectionThreadUser()

    Doug Ivison


    • 편집됨 Doug_Ivison 2013년 9월 11일 수요일 오후 5:46 Removed a parenthetical comment that was only appropriate at answers.microsoft.com, where I originally (inappropriately) posted this.
    2013년 9월 11일 수요일 오후 5:39

답변

  • Hi, Daniel, and thanks again for your reply.

    FYI, we found an answer to my most recent question to you:  where I asked where to find SERVER-2008-appropriate directions, to grant "Log on as a service" to a domain admin, IN ACTIVE DIRECTORY, on the domain server.

    The answer was found by our I/T Lead and Network Admin, Lance Godshalk.

    And yes:  it *IS* because our domain controller was under Server 2008.
    Re' that link I shared with you:  the first 5 steps are different, under Server 2008.

    Here were Lance Godshalk's steps, to add the "Log on as a service" right to an account for a Group Policy object, when you are on a domain controller under Windows Server 2008 R2: 

    1) under Start, in the text box, type "MMC" and hit enter;  that runs "Microsoft Management Console". 
    2) click the MMC pull-down menu "File", and select "Add/Remove Snap-in..."
    3) in the left frame, click "Group Policy Object Editor", then click the "Add" button.
    4) in the dialog titled "Select Group Policy Object", click "Browse".
    5) in the dialog titled "Browse for a Group Policy Object",
    we selected the tab "All", selected "Default Domain Policy", and clicked "OK".

    6) in the dialog titled "Console1", in the left frame, we clicked the "+"s to expand:
    [The rest--everything below--matches Server 2003]
    --- "Default Domain Policy [<serverName>.<domainName>.local] Policy",
    --- "Computer Configuration" 
    --- "Windows Settings"
    --- "Security Settings"
    --- "Local Policies"
    --- "User Rights Assignment"

    7) Double-click Log on as a service in the details pane.
    8) If this security setting has not yet been defined, select the Define these policy settings check box.
    9) Click Add User or Group, and then add the appropriate account to the list of accounts that possess the Log on as a service right.  (In our case, it was a group defined at the domain level, rather than a domain user.)

    ESPECIALLY NOTE: 
    For us, none of the changes took effect until we
    --- ran "GPUPDATE" (from a command prompt) on the domain server, and ALSO
    --- ran "GPUPDATE" on the server ("local machine") that immediately needed the permission to take effect.

    (Even a server restart on the "local machine" did not make the changes take effect, until after the "GPUPDATE"!)

    In our case, our final RESTART on the "local machine" was just a quick way to start all services that required that logon to "Log on as a service".  (It wasn't just SQL Server... it was also full-text indexing... at least 4 error events that had been happening were no longer a problem, in that final restart, nor since.)

    I hope this helps others,
    Be well,

    ---Doug Ivison


    Doug Ivison

    • 답변으로 표시됨 Doug_Ivison 2013년 9월 13일 금요일 오후 5:15
    2013년 9월 13일 금요일 오후 4:09

모든 응답

  • Hi,

    About KB2760411 and KB2760588, the issue did exist and Microsoft is still researching this problem.

    More available information will be post in the following links:

    MS13-073: Description of the security update for Microsoft Excel 2007 (xlconv-x-none.msp): September 10, 2013

    http://support.microsoft.com/kb/2760588

    MS13-072: Description of the security update for 2007 Office system (MSO): September 10, 2013

    http://support.microsoft.com/kb/2760411

    Since the issue that you cannot access to SQL server only occurred on one of the clients, I don’t think it was caused by this update.

    You can try the blog below:

    Named Pipes Provider, error: 40 - Could not open a connection to SQL Server

    http://blogs.msdn.com/b/sql_protocols/archive/2007/03/31/named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server.aspx

    For further support about SQL server you can refer to SQL forum:

    http://social.technet.microsoft.com/Forums/sqlserver/en-us/home?category=sqlserver

    Hope this helps.

    2013년 9월 12일 목요일 오전 9:00
  • Thanks very much, Daniel.

    THE SHORTER STORY:
    Of the machines that this update was run on, this server was the ONLY one with SQL Server on it... so that's why the update was still a key suspect. (It was my first run of these windows updates, which is usually on development machines.)  But you were right:  it was not the cause. 

    We found the cause, and a workaround...
    but there is still a Windows Server problem that I would be grateful for your help with:

    We're trying to grant permission "Log on as a service" AT THE DOMAIN CONTROLLER (in active directory), and we found directions in the 3rd section of this webpage  ((the section titled 'To add the "Log on as a service" right to an account for a Group Policy object, when you are on a domain controller or on a computer that has the Windows Server 2003 Administration Tools Pack installed')) :
    http://technet.microsoft.com/en-us/library/cc739424%28v=ws.10%29.aspx

    ... but in the operational unit's Properties (step 3), we are not seeing any "Group Policy" tab!??
    Is that because our domain server runs Server 2008 R2,
    while the webpage above says "Applies To: Windows Server 2003 R2"??
    (I tried searching for equivalent directions, that might "apply to server 2008 r2", but did not find them.)


    SO, MY QUESTION: 
    Can you help us either (1) find pertinent directions, or (2) find that "group policy" tab, in active directory?


    MORE DETAIL:

    The real cause: 
    it turns out that the development server with SQL Server on it had simply not been restarted, in over a week, so the RESTART for the update simply REVEALED a problem that had already been in existence,  ever since an unrelated incident over a week ago:  our ACTIVE DIRECTORY REBUILD. 

    We found this cause by looking in Event Viewer (readers:  one way to run that, is to Start... Run... and enter "eventvwr"), then looking at the "System" events... and we found 5 error events for source "Server Control Manager", the first of which was event 7041.  The full event text for our 7041 event is below (with our names replaced with <name>):

    The msftesql service was unable to log on as <DOMAIN>\<logon> with the currently configured password due to the following error:

    Logon failure: the user has not been granted the requested logon type at this computer.

     

    Service: msftesql

    Domain and account: <DOMAIN>\<logon>

     

    This service account does not have the necessary user right "Log on as a service."

     

    User Action

     

    Assign "Log on as a service" to the service account on this computer. You can use Local Security Settings (Secpol.msc) to do this. If this computer is a node in a cluster, check that this user right is assigned to the Cluster service account on all nodes in the cluster.

     

    If you have already assigned this user right to the service account, and the user right appears to be removed, a Group Policy object associated with this node might be removing the right. Check with your domain administrator to find out if this is happening.

     

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


    So, a permission was missing -- the logon that SQL Server starts up with, on that server, (A DOMAIN ADMIN), did not have permission on that server to "Log on as a service." 

    Note that:  that permission was not previously setup at the server level -- it was previously at the THE DOMAIN CONTROLLER / IN THE ACTIVE DIRECTORY, before our active directory rebuild -- but we're not succeeding at putting it back at that level.

    Again, note:  we got everything to work on that development server, by granting the permission at the local server... but we're concerned about other impacts from this not being setup at the domain server.
    ((For readers:  our steps to set it up at the local server:
    Start... Run... "SECPOL.msc";
    in the left frame:  expand "Local Policies", and click "User Rights Assigment";
    in the right frame:  double-click "Log on as a service"; 
    in the "...Properties" window:  click the button "Add User or Group";
    in the "Select Users..." window:  enter "Domain Admins", and click "Check Names", then click "OK";
    you'll see "<DOMAIN>\Domain Admins" added to the list... click "OK" again.
    Restart the machine. ))

    The above worked -- the server started up with no 7401 event, and SQL Server was accessible.

    But again -- we didn't used to have this right on the local server, and because this might impact multiple servers, we're looking for a way to grant it at the ActiveDirectory/DomainServer level.

    Thoughts?  Questions?  Ideas?

    Thanks much...
    ---Doug Ivison




    Doug Ivison



    • 편집됨 Doug_Ivison 2013년 9월 13일 금요일 오후 3:08
    2013년 9월 12일 목요일 오후 5:23
  • PLEASE  JUST TELL ME  IN LAYMEN  TERMS  HOW  TO GET  IT OFF  OF  MY COMPUTER!!

    TY  WILLIS  B

    2013년 9월 13일 금요일 오전 3:33
  • @justalgsoo / TyWillisB:

    I'm guessing you mean the KB's... I haven't removed them -- I'm trusting MS will fix them -- but to answer your question, I'll share two posts I saw at Answers.Microsoft.com (link below) about uninstalling:
    Today (9/10/2013)'s Office 2007 updates keep showing up...

    (The first post below looks better to me... but again, I'm only reporting it, because I'm not choosing to uninstall.)

    POST #1:
    I GOT IT SOLVED WITH MY SYSTEM:
    This was particularly frustrating because our system was using a high security VPN that would not pass traffic if any pending critical updates existed whether they were hidden or not. Those updates were conflicting with a previously installed update. I believe it was a 2007 compatibility pack that could have either been installed manually or through Microsoft update. I uninstalled all instances of the updates xx11, xx88 and xx83. Once the older 2007 compatibility pack was uninstalled I ran Windows Update and the problem cleared up. Thanks Dorr,
    http://zen-i-t.com/


    POST #2:
    Open windows Update, in the bottom L/hand corner, open Installed Updates & right click on each update separately and click on uninstall.
    Go back to the updates in Windows update. Clear the check boxes, right click on each Update & Click on Hide update. Run Windows update again & check to see that they are gone.
    This worked for me.
    Jim Lewis

    I hope that helps! 
    --Doug Ivison


    Doug Ivison

    2013년 9월 13일 금요일 오후 3:07
  • Hi, Daniel, and thanks again for your reply.

    FYI, we found an answer to my most recent question to you:  where I asked where to find SERVER-2008-appropriate directions, to grant "Log on as a service" to a domain admin, IN ACTIVE DIRECTORY, on the domain server.

    The answer was found by our I/T Lead and Network Admin, Lance Godshalk.

    And yes:  it *IS* because our domain controller was under Server 2008.
    Re' that link I shared with you:  the first 5 steps are different, under Server 2008.

    Here were Lance Godshalk's steps, to add the "Log on as a service" right to an account for a Group Policy object, when you are on a domain controller under Windows Server 2008 R2: 

    1) under Start, in the text box, type "MMC" and hit enter;  that runs "Microsoft Management Console". 
    2) click the MMC pull-down menu "File", and select "Add/Remove Snap-in..."
    3) in the left frame, click "Group Policy Object Editor", then click the "Add" button.
    4) in the dialog titled "Select Group Policy Object", click "Browse".
    5) in the dialog titled "Browse for a Group Policy Object",
    we selected the tab "All", selected "Default Domain Policy", and clicked "OK".

    6) in the dialog titled "Console1", in the left frame, we clicked the "+"s to expand:
    [The rest--everything below--matches Server 2003]
    --- "Default Domain Policy [<serverName>.<domainName>.local] Policy",
    --- "Computer Configuration" 
    --- "Windows Settings"
    --- "Security Settings"
    --- "Local Policies"
    --- "User Rights Assignment"

    7) Double-click Log on as a service in the details pane.
    8) If this security setting has not yet been defined, select the Define these policy settings check box.
    9) Click Add User or Group, and then add the appropriate account to the list of accounts that possess the Log on as a service right.  (In our case, it was a group defined at the domain level, rather than a domain user.)

    ESPECIALLY NOTE: 
    For us, none of the changes took effect until we
    --- ran "GPUPDATE" (from a command prompt) on the domain server, and ALSO
    --- ran "GPUPDATE" on the server ("local machine") that immediately needed the permission to take effect.

    (Even a server restart on the "local machine" did not make the changes take effect, until after the "GPUPDATE"!)

    In our case, our final RESTART on the "local machine" was just a quick way to start all services that required that logon to "Log on as a service".  (It wasn't just SQL Server... it was also full-text indexing... at least 4 error events that had been happening were no longer a problem, in that final restart, nor since.)

    I hope this helps others,
    Be well,

    ---Doug Ivison


    Doug Ivison

    • 답변으로 표시됨 Doug_Ivison 2013년 9월 13일 금요일 오후 5:15
    2013년 9월 13일 금요일 오후 4:09