Jump to content


FBF

New Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About FBF

  • Rank
    Newbie
  1. Just in case my solution helps anybody suffering from this issue (0x80072ee2 error code). And without reinstalling WSUS. In my case I have 3 SUPs. Updates Deployments are usually going well for almost all the machines. However yesterday I had to deploy urgently a KB from 5 months ago to some machines that supposedly already should have been installed. Since most of the computers were able to deploy updates I thought of a specific problem on those PC's. I checked the SCCM client logs but nothing. Then I checked the C:\windows\windowsupdate.log (they are W7). There I found the infamous 0x80072ee2 error code. Nothing useful on the Internet. Tried to verify if there was a connection issue. Nope, the client can reach the WSUS/SUP TCP ports. Then I started realising that always the same SUP server was referenced where the error appeared. I logged into that server and restarted the "WSUS Server" service and tried running the updates scan again. Nothing seemed to happened, but then I read carefully the error description: SendRequestUsingProxy failed for <http://sup01.domain.com/Content/7A/BDB34A0FD82AA65E1E173D46371ACB9BAD142FDB.txt>. error 0x80072ee2. That URL didn't work from any computer, but switching to another SUP server it worked (http://sup02.domain.com/Content/7A/BDB34A0FD82AA65E1E173D46371ACB9BAD142FDB.txt). Went back to the "SUP01" server, opened IIS Manager, browsed to "SUP01\Sites\WSUS Administration" and clicked on the "Content" dir. Well, I must admit that I previously had a bad time with that folder because of our multiple SUP servers configuration so it was familiar. And there it was: At some moment the address of the network folder where WSUS Content dir was located was changed by SysAdmin requirements, and somehow that address was updated on every SUP (IIS) server but the SUP01. Once I set the proper path (via the Basic Settings button) I clicked on "Test Settings" to verify everything is correct. A new window with two green checks should be listed. Now you can clic on the virtual "Content" dir and all the folder content will be listed. There's one thing more to do: You need to restart the "WsusPool" Application Pool (it may take some time). Maybe you should want to restart the "WSUS Server" service. After that you should be able to browse the http://sup01.domain.com/Content/7A/BDB34A0FD82AA65E1E173D46371ACB9BAD142FDB.txt URL from anywhere, and of course, run a updates scan action. To sum it up: Find the failing SUP server from windowsupdate.log Try to browse the URL windowsupdate.log reported the 0x80072ee2 error code for. Login to that SUP server and open IIS Manager (not IIS 6 Manager, please). Browse to "SUP01\Sites\WSUS Administration" and click on "Content". If the content of this folder is not expanded, then there's a problem with IIS accessing to this folder, which translates to SUP not working. With the focus on the "Content" folder click on the "Basic Settings" in the "Actions" pane. Make sure the specified "Physical path" exists and it's the one you specified when you set up WSUS. Click on "Test Settings". If both check actions don't return a green check, please make sure the server IIS account or the alternative user account you may have specified in "Connect as" button has the proper rights specified by the WSUS documentation. Once the "Test Settings" button returns two green checks, save the changes and try to browse the virtual "Content" dir from the IIS Manager. If the browsing succeeded, go to "Application Pools" and restart (I did Stop/Start) the "WsusPool". Finally, maybe you would like to restart the "WSUS Server" service on the SUP server. This post is provided AS-IS with no warranties or guarantees and confers no rights. Use these information at your own risk.
  2. Just in case the posted solution didn't work for you, like it was my case: In my case the "BgbServer.log" log file was reporting login errors of the MP server connecting to the Database (located at a different server). Error message: ERROR: Can't retrieve SQL connection - Cannot open database "CM_XXX" requested by the login. The login failed The thing was that I reinstalled the MP server using the same name. In the SCCM database (CM_XXX) at SQL Server the server's account logically was already defined, but since the MP server has been reinstalled, it is a different machine (probably because SQL Server is using the machine's SID). The solution steps I took: Open SQL Server Management Studio and connect to the server which holds the SCCM database (CM_XXX). Browse to "Databases\CM_XXX\Security\Users" Edit the already existing MP server's account (for example "Domain\MPServer$") and take screenshots of every property (General, Owned Schemas, Membership, etc...) Delete the already existing MP server's account (do not delete it from the "Security\Logins" section, it's not necessary) Add the "Domain\MPServer$" account back to the "Databases\CM_XXX\Security\Users" section, setting the same same properties as shown in the screenshots you took in step 3. After that, you don't have to do anything else, not even reboot, in a matter of minutes it will automatically start working and you should be able to successfully check MP status (http://<ServerName>/sms_mp/.sms_aut?mplist) Hope this helps.
×
×
  • Create New...