'Error: Connection Error' when connecting to WSUS 3.0 via MMC
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
- tswebI 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 the 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
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- Marked As Answer byEric Zhang - MSFTMSFT, ModeratorMonday, July 14, 2008 9:02 AM
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)
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 : 0x0This 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
SystemStack 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.AdministrationStack 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........Can you check the IIS log files and see what responses you are getting back from the ApiRemoting30 webservice?
- Joe
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 workingAny ideas ??
Thanks,
RogerSystem.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- 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- Marked As Answer byEric Zhang - MSFTMSFT, ModeratorMonday, July 14, 2008 9:02 AM
- 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
- 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
