Sign in
 
Home2012Previous VersionsLibraryForumsGallery
System Center TechCenter >
> 
> 
WSUS and SCCM 2007 on Same Server

Answered WSUS and SCCM 2007 on Same Server

  • Wednesday, September 12, 2007 3:10 PM
     
     
    Sign In to Vote
    0

    Doh! didn't realise my xbox gamertag was going to appear as the authors name, and before anyone asks I am not vertically challenged........  

     

    Anyway to my question, hope someone can help as this is starting to do my head in.

     

    I setup a SCCM2007 in our test lab and as there was a lack of other hardware I decided to put WSUS on it as well.  Its quite a beefy server so is more than capable of running both. 

     

    Anyway WSUS is working fine, it goes through our proxy server for updates from the MS updates.  The problem sees to be with the SCCM server.  I have setup the "ConfigMgr Software Update Point" role and told it not us use a proxy when syncronising.  The Software Update Point Component Configuration is set to use the Software Update Point on the local server and Sync with Microsoft Updates.  This one I wasn't entirely sure about as I thought it would syncronise with the WSUS server as its the WSUS that syncs with Microsoft Updates. 

     

    Anyway I have checked the WSUSCtrl.log and see the following:

     

    Found WSUS Admin dll of assembly version Microsoft.UpdateServices.Administration, Version=3.0.6000.273, Major Version = 0x30000, Minor Version = 0x17700111 
    Found WSUS Admin dll of assembly version Microsoft.UpdateServices.Administration, Version=2.0.0.0, Major Version = 0x20000, Minor Version = 0x0 
    The installed WSUS build has the valid and supported WSUS Administration DLL assembly version (3.1.6000.1) 
    Successfully connected to local WSUS server 
    Local WSUS Server Proxy settings are correctly configured as Proxy Name PROXY and Proxy Port 80 S
    Waiting for changes for 57 minutes 

     

    Which I take means that as far as SCCM is concerned WSUS is the correct version etc

     

     

    If I look at the wsyncmgr.log I see this error

     

    Sync failed: WSUS server not configured. Source: CWSyncMgr:Big SmileoSync SMS_WSUS_SYNC_MANAGER 12/09/2007 14:13:05 5496 (0x1578)

     

    I have reinstalled WSUS several times but cannot get rid of this error.

     

    I am running the RTM version of SCCM but this was installed as a upgrade to the previous version.

     

     

All Replies

  • Wednesday, September 12, 2007 4:54 PM
     
     Answered
    Sign In to Vote
    0
    It also took me some time to figure it out, especially the beta was bugged here, but this is the way to do it:

    1. Install WSUS 3.0 and abort the wizzard after the installation (= Don't configure anything in WSUS)
    2. Install the "ConfigMgr Software Update Point" Role and configure your proxy settings (I assume thats the missing step)
    3. Configure Software Update Point Component: "Active software update point on site server" and "Synchronize from Microsoft Update".
    Make sure the ports are correct (and select the updates you wish to receive - the product list will be updated after the first sync)

    So the highest Software Update Point in the hierarchy needs a local WSUS installation and takes it completly over,
    you will notice that the settings in SCCM will be reflected on the WSUS Console...
     
  • Thursday, September 13, 2007 7:58 AM
     
     Answered
    Sign In to Vote
    0

    I think you have it right.

     

    To be clear:

     

    The WSUS settings are automatically controlled by SCCM, including the proxy settings - it looks like you may have not set the proxy settings in SCCM, which would mean that the WSUS server would not be able to get out to MU.

     
  • Thursday, September 13, 2007 11:18 AM
     
     
    Sign In to Vote
    0

    Thanks for the info. WSUS can contact the MU site, the issue seems to be the SCCM server can sync with the WSUS server.  I had also configured the proxy settings as well but still couldn't get it to work.  I wonder if the problem is that WSUS is installed on the same server although I wouldn't have thought so.

     
  • Thursday, September 13, 2007 7:42 PM
     
     Answered
    Sign In to Vote
    0

    When synchronization is initiated at the site, WSUS Synchronization Manager connects to WSUS using the port settings specified when creating the active software update point.  By default, port 80 is used for HTTP and port 443 for HTTPS (SSL).  There are no checks to the WSUS Web site verifying that these ports are the ones configured for the WSUS Web site.  One of the typical reasons for the error you are seeing in the log file is because these settings are configured differently for the active software update point and WSUS Web site. 

     

    Check the port settings configured for the active software update point, and make sure they are the same as the port settings configured for the Web site used by the WSUS server.  For example, if a custom WSUS Web site is used when configuring WSUS, port 8530 and 8531 are automatically configured for the Web site. For the procedure about how to check the port settings for the WSUS Web site, go to http://technet.microsoft.com/en-us/library/bb632477.aspx.  Check the port settings on the active software point by going to the Software Update Point Component properties and verify that they match the WSUS Web site settings.

     
  • Thursday, September 27, 2007 3:17 PM
     
     
    Sign In to Vote
    0

    I am also having this issue. Here is what I have done so far (to no avail)...

     

    All of this is on a single server.

    1. Installed Windows Server 2003 / SP2 and all updates
    2. Installed SQL 2005 and SQL 2005 SP2
    3. Added IIS (including ASP and BITS)
    4. Updated BITS to 2.5 (KB 923845)
    5. Installed WSUS 3.0. Used SQL for the DB. Used a custom web site (ports 8530/8531). Sync with Microsoft Update. Did not choose to give it a folder to download updates to (this will be managed by SCCM)
    6. Installed SCCM RTM Eval in Mixed Mode.
    7. Added Software Update Point. Active SUP on site server...ports 8530/8531...no ssl...synchronize from Microsoft Update
    8. there is no proxy server involved in this environment

    Immediately after installing with those settings, SCCM attempts to connect with WSUS to finish it's configuration and to synchronize the updates catalog. The first time it does so, the following error appears in the SMS_WSUS_SYNC_MANAGER log:
    >>>>>>>>>
    SMS WSUS Synchronization failed.
    Message: The request failed with HTTP status 401: Unauthorized.
    Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.
    The operating system reported error 2147500037: Unspecified error
    >>>>>>>>>

    After this, every time SCCM tries to synchronize the catalog (Computer Management / Software Updates / Update Repository / "Run Synchronization"), the following error appears:
    >>>>>>>>
    SMS WSUS Synchronization failed.
    Message: WSUS server not configured.
    Source: CWSyncMgr:Big SmileoSync.
    The operating system reported error 2147500037: Unspecified error
    >>>>>>>>

    I have removed and reinstalled both WSUS and the SUP multiple times, but still can't get it working. I even went so far as to create another virtual server and reinstall everything from scratch, but all I succeeded in doing was replicating the problem.

    Anyone got a clue as to what might be going on and how to fix it?

    Thanks in advance.

    Jarvis

    EDIT: Actually a better copy of the 401 message came from the wcm.log file...

    >>>>>>>>>>>
    System.Net.WebException: The request failed with HTTP status 401: Unauthorized.~~   at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~   at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)~~   at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber)
    >>>>>>>>>>>>

    If I read that error correctly (following the three "at"s in the message)...
    the 401 is spit out by Microsoft.UpdateServices.Administration.AdminProxy.createupdateserver
    which comes from Microsoft.UpdateServices.Administration.AdminProxy.getupdateserver
    which come from Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer

    So...is it tied to it not being able to connect to the WSUS server? and if so...WHY will it not connect!!! This should be a fairly simple setup that I have spent way too much time getting it to not work.

     
  • Thursday, September 27, 2007 5:27 PM
     
     Answered
    Sign In to Vote
    0

    Check the Internet Information Services (IIS) permissions on DssAuthWebService virtual directory for the WSUS Web site. The virtual directory must be enabled for anonymous access. By default, the IUSR_<ComputerName> account is used for anonymous access. Check that this account has appropriate rights, for example, if this account is a member of the Guests group access might be denied.

     

    This possible solution is part of the new troubleshooting content that will be in the November update to the software updates Web documentation.  And here is the procedure to configure the anonymous access:

    -----------------------------

    When WSUS Synchronization Manager on child sites receive a synchronization request from the parent site, anonymous access must be enabled on the DssAuthWebService virtual directory for the WSUS Web site in Internet Information Services (IIS). Use the following procedure to verify and configure that anonymous access is enabled on the virtual directory.

    To configure anonymous access on the DssAuthWebService virtual directory

    1. On the WSUS server, open Internet Information Services (IIS) Manager.

    2. Expand Web Sites, and then expand the Web site for the WSUS server. It is recommended that the WSUS custom Web site be used, but the default Web site might have been chosen when installing WSUS.

    3. Right-click DssAuthWebService, and then click Properties.

    4. Click the Directory Security tab, and then click Edit in the Authentication and access control section.

    5. Verify that Enable anonymous access is selected and that the IUSR_<ComputerName> account is specified.

    I hope this helps!

     

    Doug

     
  • Thursday, September 27, 2007 6:21 PM
     
     
    Sign In to Vote
    0

    Thanks for the reply Doug. I had great hopes when I first read your post...unfortunately it wasn't the problem. the IUSR account already was set up for annonymous access. I checked the perms, and everything looks as it should. I removed that account from the Guest group just for grins, but it still failed. I have seen (still have access to see) another server with the "same" setup that is able to synchronize fine (with IUSR as part of Guest). I even went into the file system and pulled an effective permissions...iusr has read.

     

    Just a note...unless I am really missing something...that's not the account that it should be using to connect to configure WSUS...it's the site system account (server's computer account). isn't that right?

     

    Got any other ideas? I've been beating on this for nearly two weeks at this point.

     

    Thanks in advance,

    Jarvis

     
  • Thursday, September 27, 2007 7:44 PM
     
     Answered
    Sign In to Vote
    0

    Hey Jarvis, I have only seen the 401 error when IIS permissions are not configured appropriately for ConfigMgr to connect to the WSUS server. When there is a problem with WSUS or ConfigMgr the error is different in my experience. In fact, I just repro'd the 401 error on my site server as follows:

    1. Open the IIS console
    2. Expand the WSUS Administration Web site
    3. Right-click ApiRemoting30, and then click Permissions.
    4. Deny permissions to System or Administrators.  Either one with Deny permissions will cause this error.
    5. Open the ConfigMgr console, go to the Update Repository node, and then run the Run Synchronization action.

    I get the same error as follows in the wsyncmgr.log:

    Sync failed: The request failed with HTTP status 401: Unauthorized. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer SMS_WSUS_SYNC_MANAGER 9/27/2007 12:39:30 PM 3720 (0x0E88)

    So, this isn't necessarily your answer, but can you check the permissions on the ApiRemoting30 virtual directory and see what you have?  I'm not an IIS expert, but hopefully this points you in the right direction.

     

    Thanks,

     

    Doug

     
  • Monday, October 01, 2007 2:22 PM
     
     
    Sign In to Vote
    0
    In Internet Explorer do you have proxy settings set to auto?  If so this needs to be disabled, if this is configured through GPO (unlikely since you are in a lab) you can set it there by making an exception for your server, otherwise start a cmd prompt window running as local SYSTEM and then start IE, check the prosy settings there and if they are set to auto detect, like you need to have them for the first release of SCCM trail bits, then uncheck that box and try the sync.

    Make sure you have your FQDN configured in ConfigMgr, and all .NET patches installed.

    Also if I recall correctly there was an issue in the beta when you had WSUS installed prior to installing ConfigMgr.  I have actualy done an upgrade of SMS 2003 to ConfigMgr (article out soon) in my home lab and did the install of WSUS during my post install configuraitons and it is installed on the same server and working.

    Regards,
    Anthony

    My blogs:
    http://myitforum.com/cs2/blogs/socal
    http://ConfigMgr.com
     
  • Wednesday, October 10, 2007 12:33 PM
     
     
    Sign In to Vote
    0

    If you installed WSUS after SCCM, it probably installed to a different port than port 80 because SCCM components were using port 80.  When configuring the Software Update point, you probably used the default port 80 for non SSL communications, rather than the port to which WSUS was installed.

     

    You need to run IIS Manager and find out what port "WSUS Administration" is using, then reconfigure the Software Update point to use that port.

     

     
  • Tuesday, October 23, 2007 7:30 PM
     
     Answered
    Sign In to Vote
    0

     

    Well...I got this resolved. Short answer is that it is related to proxy issues (even though the proxy is not required and all proxy checkboxes are unchecked). I've posted a full detailed description of the problem, symptoms, log entries, and my analysis (with a workaround) on my blog that you can check out if you want more info.

    Hope this helps others out there.

    Jarvis


    http://verbalprocess.wordpress.com/2007/10/23/sccm-and-wsus-issues/

     
  • Thursday, October 25, 2007 7:24 AM
     
     Answered
    Sign In to Vote
    0

    Here is the explanation from one of the Dev Leads about this issue that will hopefully clarify some of the unknowns here:

     

    "  “SCCM appears to be getting proxy auto-config info even though the proxy boxes are unchecked.”

    This proxy setting that he is un-checking only affects WSUS sync from MU, this will not affect WSUS SDK usage.

     

    The WSUS SDK uses webservices for its clients (SCCM in our case) to connect to it. From our usage we just have a Connect method that takes the WSUS Server Name (FQDN or NetBIOS) and Port # (80/443 or 8530/8531). Internally the WSUS SDK does a http/https call to their webservice using http://server.company.com:8530/ApiRemoting30/WebService.asmx

     

    Now the issue is that the proxy configuration for this customer should be such that it should treat this as an internal address and bypass it. Now most of the customers add this to IE proxy server exception list but this only affects the logged-on user’s setting. Since we run under localsystem they need this to be change for the system. They can do this by running IE as local system and doing this OR use the ProxyCfg.exe tool (I have not tried this but someone mentioned on smstalk).

     

    Either way this is external to SCCM..."

     

     
  • Tuesday, September 16, 2008 6:48 PM
     
     
    Sign In to Vote
    0

     

    Hi Marc,

     

    I am facing the same or similar issues as in the post. I have however found the following in the IIS log for the WSUS website.

     

    2008-09-16 18:02:45 W3SVC548496216 ?????????? ??????????? POST /ApiRemoting30/WebService.asmx - 8530 - ?????????? HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.1433) - - ??????????:8530 401 1 0 0
    2008-09-16 18:02:45 W3SVC548496216 ?????????? ?????????? POST /ApiRemoting30/WebService.asmx - 8530 domain\machineaccount$ ??????????? HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.1433) - - ??????????:8530 200 0 0 15

     

    I have obscured servers and users by ??????. What I read from this is that when the http request gets to ApiRemoting using the machine account (second log entry) it succeeds but when it is nothing/anonymous it fails (first log entry).

     

    How can I eithe rfind out where to change SCCM to not use anonymous or to allow anonymous to this ApiRemoting virtual directory.

     

    Any help will be appreciated as I have been busy with this for the last few weeks now and have rebuilt, reinstalled etc and ready to throw the lot out.

     
  • Tuesday, September 16, 2008 7:41 PM
     
     
    Sign In to Vote
    0
     Marc Umeno [MSFT] wrote:

     

    Now the issue is that the proxy configuration for this customer should be such that it should treat this as an internal address and bypass it. Now most of the customers add this to IE proxy server exception list but this only affects the logged-on user’s setting. Since we run under localsystem they need this to be change for the system. They can do this by running IE as local system and doing this OR use the ProxyCfg.exe tool (I have not tried this but someone mentioned on smstalk).

     

    Either way this is external to SCCM..."

     



    I can confirm this, if you are using ISA as the proxy server and IE is configured to get settings automatic from the web, and proxycfg does not return any settings, clients will try to go through the ISA server even if all the servers are internal.

    The only way to fix this is to set proxycfg to point to the wpad location and configure an exeption for the FQDN domain adress (*.domain.local). Doing so you will get the correct behaviour and clients will report back to the wsus server.

    As we use ISA with authentication, and we setting proxycfg on every computer was not an option we had to set a ISA rule to allow anonymous access to the ISA server and direct the to the WSUS server.... not a good fix but we found no better way as setting proxycfg was way more messy.