none
'Error: Connection Error' when connecting to WSUS 3.0 via MMC

    Question

  • Hi there,

    OS: W2K3, WSUS 3.0
    I
    just use this forum, since I can’t get any help elsewhere.
    (Can somebody help me as an active Terminal Services participant on this forum)
    I get the above error message (Error: Connection Error) when I try to open the WSUS 3.0 console 
    on the WSUS server (W2K3). It worked fine before.
    The problem occurred when I was testing on this production server (stupid me, I know, I know). I added 
    tsweb for testing purposes on the same machine.
    Normally no problem, but I did more. I changed security settings in IIS to tighten the security. Actions done:
    - connect to IIS
    - go to Default Web Site properties
    - go to Directory Security and choose Edit in the ‘Authentication and access control’ section.
    - in this screen I deselect ‘Enable anonymous access’
    From this moment I was not able to use the default web site, which contains:
    - default website
    - wsus
    - tsweb
    I reversed the action by selecting ‘Enable anonymous access’. Later I discovered that I had to 
    re-enable security via the Home Directory tab as
    well. I had to enable Read and Directory
    browsing access.
    By doing this, tsweb and the default website where accessible again. But not WSUS. I still 
    get the error I specified above.
    I think it has to do with IIS, or ntfs directory security, but I have not enough IIS knowledge to 
    solve this issue. Is somebody able to push me into t
    he right direction?
    At the moment I’m unable to control my WSUS environment. 
    When I connect via my local machine I get a different error:
    Error: Permissions Error
    A permissions error occured when trying to perform an operation on this
    server. This can happen if your permissions have changed since connecting to
    the server. Please contact your system administrator if the problem persists.
     
    Let me know what to do.
    Sincerely,
    Yuri

    Thursday, February 07, 2008 1:07 PM

Answers

  • Hi if you have a server with WSUS working on it, then try comparing the security of the following folders form the working server with those of the other server which is failing. If you have only one server then email me the security setting of the folders and files for me to take a look at.
    1. Drive:\WSUS
    2. Drive:\WSUS\UpdateServicesDbFiles
    3. Drive:\WSUS\UpdateServicesDbFiles\SUSDB.mdf
    4. Drive:\WSUS\UpdateServicesDbFiles\SUSDB_log.ldf
    5. Drive:\WSUS\UpdateServicesPackages
    6. Drive:\WSUS\WsusContent
    7. Drive:\Program Files\Update Services\administrationsnapin
    8. Drive:\Program Files\Update Services\Common
    9. Drive:\Program Files\Update Services\Inventory
    10. Drive:\Program Files\Update Services\LogFiles
    11. Drive:\Program Files\Update Services\Selfupdate
    12. Drive:\Program Files\Update Services\WebServices
    Friday, June 27, 2008 6:22 PM

All replies

  • *update*

    I’m also unable to connect with another user (ie enterprise domain admin).

    Actions taken:
    - I logon to the server with another user account.
    - Go to Administrative Tools >  Microsoft Windows Update Services 3.0
    - It is the first time with this user account so I have to define the server.

    - The following error is on my screen:

    Connect to Server

    Cannot connect to ‘<servername>’. You do not have the permissions required to access this WSUS server.


    To connect to the server you must be a member of the WSUS Administrators or WSUS Reporters security groups.

     Retry – Cancel

     

    (FYI: the user is in the security groups listed)

    Tuesday, February 12, 2008 2:41 PM
  • I am running into the same issues. As I was connected to the server via the console and waiting for intial synchronization to finish, an error appeared which gave me the opportunity to Copy to Clipboard:

     

    The WSUS administration console was unable to connect to the WSUS Server via the remote API. [the console is being run from the server itself]

    Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists, try restarting IIS, SQL, and the Update Services Service.[had to restart IIS and the Update Services, but am unable to restart the Windows Internal Database (Microsoft##SSEE) service; results in the following error: "Windows is unable to start this service. Review the system Event Log". The details from the system event log are:

     

    Event Type: Error
    Event Source: Service Control Manager
    Event Category: None
    Event ID: 7024
    Date:  2/20/2008
    Time:  10:48:20 AM
    User:  N/A
    Computer: HWKSVRSVC1
    Description:
    The Windows Internal Database (MICROSOFT##SSEE) service terminated with service-specific error 5 (0x5).

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

    Following the help and support link, I executed the requested command line syntax decribed and obtained the following result:

     

    C:\Documents and Settings\Administrator.MPDOMAIN>sc query mssql$microsoft##SSEE

    SERVICE_NAME: mssql$microsoft##SSEE
            TYPE               : 10  WIN32_OWN_PROCESS
            STATE              : 1  STOPPED
                                    (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))

            WIN32_EXIT_CODE    : 1066  (0x42a)
            SERVICE_EXIT_CODE  : 5  (0x5)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0

     

    This domain administrator account is a member of the WSUS Administrators group on my WSUS server.

    The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists,

    Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.


    System.IO.IOException -- The handshake failed due to an unexpected packet format.

    Source
    System

    Stack Trace:
       at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
       at System.Net.TlsStream.CallProcessAuthentication(Object state)
       at System.Threading.ExecutionContext.runTryCode(Object userData)
       at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
       at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
       at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
       at System.Net.ConnectStream.WriteHeaders(Boolean async)
    ** this exception was nested inside of the following exception **


    System.Net.WebException -- The underlying connection was closed: An unexpected error occurred on a send.

    Source
    Microsoft.UpdateServices.Administration

    Stack Trace:
       at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)
       at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)
       at Microsoft.UpdateServices.UI.AdminApiAccess.AdminApiTools.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.GetUpdateServer(PersistedServerSettings settings)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.ConnectToServer()
       at Microsoft.UpdateServices.UI.SnapIn.Scope.ServerSummaryScopeNode.get_ServerTools()

     

    HELP MICROSOFT!! I'M TRYING TO USE YOUR PRODUCT........
    Wednesday, February 20, 2008 3:58 PM
  • Can you check the IIS log files and see what responses you are getting back from the ApiRemoting30 webservice?

     

    - Joe

     

    Wednesday, February 27, 2008 11:28 PM
    Moderator
  • Sorry to jump in on this, but it is the most close active thread with MSFT on this I can find on the net.  I have a thread so far going nowhere in microsoft.public.windows.server.update_services started with posting news:uPVEF7SiIHA.5160@TK2MSFTNGP05.phx.gbl

     

    This is also on W2k3 (R2) with a WSUS install that was fresh at v3 and is now updated to v3 Sp1.  I am hoping to role out machine group based reporting to those responsible for the client systems, but am meeting with a deadend in troubleshooting.

     

    Attempts to connect to WSUS using the WSUS console mmc fail with a message that the account must be a member of the WSUS Administrators or WSUS Reporters group

    However, the account is a member (of either, happens each way).

     

    The WSUS is in production and updated to SP 1 apparently successfully except for this new feature's failure to function as designed.

     

    The accounts tried do have all server-level rights/grants and can log into the server running WSUS as shown both by the event log and by doing so.

    The account can be either a domain group or a local account using a matching local account (same name+pwd on client and server).  The server running WSUS and the test client machine and domain account are all in the same domain in multidomain forest.

    The WSUS console failure to connect happens either when the mmc is used on a remote client or when the account is logged in locally to the server running WSUS.  (Remote use of the WSUS console mmc is the intended practice, local login was enabled for this troubleshooting only.)

     

    If the account is made a member of the server's Administrators group connection with the WSUS console mmc works.

     

    The failure to connect with the WSUS console is accompanied by an http 500 status code in the IIS logs for the hit on webservice at ApiRemoting30/WebService.asmx (following the initial 401 to the unauthenticated access attempt) and show the test account was successfully authenticated.

     

    The registry permissions are correct according to what is stated in the WSUS Operations Guide v1.2.  The server running WSUS has an NTFS audit ACL so that any access attempt that fails by any account to anything in the filesystem will generate an event
    log record.  No filesystem access failures are being recorded.
    The NTFS ACLing for the WSUS install areas are also correct according to the WSUS Operations Guide v1.2
    (PS. I think there are some errors in the info provided in the guide which I mention in the thread on msnews linked above)
    The .Net CAS policy is at the OS install default of Full trust.
    Nothing is showing in the SQL logs (of the bundled WSUS install of its modified SQL express) that is time-correlated to failing access attempts.

    I have enabled tracing for the ApiRemoting30 app via its web.config file.
    When viewing the traces via trace.axd each of them is showing nothing except the headers and server variables collections.
    Curiously one error message was logged in the server's application event log at what appears to have been the time when the app was triggered to compile (i.e. recorded only once, not for each connection attempt).
    It is Type Error Event ID 12012 from Source Windows Server Update of Category Web Service with Description:
    The API Remoting Web Service is not working

    Any ideas ??

    Thanks,
    Roger

    Thursday, March 20, 2008 3:59 PM
  •  

    System.IO.IOException -- The handshake failed due to an unexpected packet format.





    this also happens when IIS default website is bound to a specific address (instead of All Unassigned) and you then subsequently change the servers actual address.

    Forgetting to change the binding in IIS to match the new server address raises the same error.



    Chris Leech
    Monday, June 16, 2008 6:39 AM
  • Hi if you have a server with WSUS working on it, then try comparing the security of the following folders form the working server with those of the other server which is failing. If you have only one server then email me the security setting of the folders and files for me to take a look at.
    1. Drive:\WSUS
    2. Drive:\WSUS\UpdateServicesDbFiles
    3. Drive:\WSUS\UpdateServicesDbFiles\SUSDB.mdf
    4. Drive:\WSUS\UpdateServicesDbFiles\SUSDB_log.ldf
    5. Drive:\WSUS\UpdateServicesPackages
    6. Drive:\WSUS\WsusContent
    7. Drive:\Program Files\Update Services\administrationsnapin
    8. Drive:\Program Files\Update Services\Common
    9. Drive:\Program Files\Update Services\Inventory
    10. Drive:\Program Files\Update Services\LogFiles
    11. Drive:\Program Files\Update Services\Selfupdate
    12. Drive:\Program Files\Update Services\WebServices
    Friday, June 27, 2008 6:22 PM
  • Hi Yuri,

    As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios.

    If the issue still persists and you want to return to this question, please reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish.

    In addition, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.

    Thanks!
    --------------------
    Regards,
    Eric Zhang

    Monday, July 14, 2008 9:02 AM
    Moderator
  • In our case, this WSUS error was caused by installing Sharepoint on the same server where WSUS was running.

    I found this link, which explains why this happens, and offers a resolution.

    http://wss.collutions.com/Lists/FAQ/DispForm.aspx?ID=530
    Tuesday, July 15, 2008 10:49 AM