Configuring IIS 7 on Server 2008 for WSUS 3

Discussion in 'Update Services' started by Bruce Sanderson, May 10, 2008.

  1. The page at
    says to modify the system32\inetsrv\applicationhost.config file after
    installing IIS 7 on Windows Server 2008. I'm finding this instruction a bit
    puzling and wonder if anyone can shed some light on it.

    I'm in the process of moving my existing WSUS 3.0 from a Windows Server 2008
    (RTM) 32 installation to a Windows Server 2008 (RTM) 64 bit installation.
    The WSUS installation on the 32 bit server has been operating since it was
    installed shortly after Windows Server 2008 went RTM. I previously had it
    installed on a beta release of Windows Server 2008.

    The WSUS server on the 32 bit server appears to be functioning normally -
    clients are getting updates and it syncronizes with Microsoft Windows Update

    1. on the 32 bit server I did not make any changes to the IIS
    applictionhost.config file, but WSUS is working correctly - so what is this
    change supposed to do?

    2. There does not appear to be a file called applicationhost.config in the
    folder system32\inetsrv on either the 32 bit or 64 bit Windows Server 2008.
    There is however an applicationhost.config file in the folder
    system32\inetsrv\config on both the 32 bit and 64 bit server (there is no
    applicationhost.config in syswow64\inetsrv\config folder on the 64 bit
    server). Is this a simple mistake in the above document or does this
    instruction only apply if there is an applicationhost.config file in the
    system32\inetsrv folder?

    3. What are the implications of NOT making the change specified in the
    "Configuring IIS 7.0" section of the above page?

    By way of information, in the file
    system32\inetsrv\config\applicationhost.config, there is a
    <system.webServer><modules> tag and there is also a line with <add
    name="CustomErrorModule"> inside that tag.
    Bruce Sanderson, May 10, 2008
    1. Advertisements

  2. A more precise URL would have helped a bit <g>

    You got lucky? :)

    Actually.. as you'll read momentarily, this is not an issue that affects any
    normal operation of WSUS.

    It ensures that the module "CustomErrorModule" is *not* loaded for this

    No doubt a technical error in the documentation. I'll send an email to the
    team noting the inaccuracy.

    Edit the file that exists = wherever it happens to be. There is only =one=
    applicationhost.config file on an IIS server.

    =IF= an error is thrown by the WSUS services (which use ASP.NET v2.0), the
    'client' would get the "Custom" error messages -- which are pretty useless
    to a services-based client. Net total effect, the IIS Server sends a bunch
    of "information" back across the wire that is totally useless to the Windows
    Update Agent.

    The "CustomErrorModule" is designed for interactive applications, where a
    human would read the error information in the browser, and be able to
    respond accordingly.

    Correct... change the word "add" to "remove", and you're done.

    Lawrence Garvin, M.S., MCITP, MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website:
    My Websites:;
    My MVP Profile:
    Lawrence Garvin [MVP], May 10, 2008
    1. Advertisements

  3. Thanks, Lawrence.

    Your explanation is exemplory!

    Sorry about the URL thingy, but I copied the URL directly out of the IE 7
    Addressbar while the "Configure IIS" was displayed, so I assumed it was the
    right one. I now notice that if I click on any item in the left pane in the
    "Microsoft Windows Server TechCenter", the URL in the IE Addressbar does not
    change, just the right pane content. However, if I right click on "Install
    the WSUS 3.0 Server/Configure IIS", select Open in new Tab, the Addressbar
    in the new tab shows the one you provided. I'll try and remember that in
    the future!

    Thanks again for the quick and complete response.
    Bruce Sanderson

    It is perfectly useless to know the right answer to the wrong question.
    Bruce Sanderson, May 11, 2008
  4. Bruce Sanderson

    Ken Schaefer Guest

    Hi there,

    a) the file path in the article is a mistake. As you note, that file is
    located in \config folder, not in the inetsrv folder

    b) I'm not really sure /why/ this guidance is there. I am running WSUS 3.0
    on Windows Server 2008 with the custom error module installed without any
    untoward issues.

    Additionally, the guidance in the document will remove the CustomErrorModule
    for *all* websites on your server (unless you manually re-add the
    CustomErrorModule specifically for each website). That doesn't sound like
    good guidance to me.

    Additionally, the <remove> tag must come after the <add> tag, otherwise it
    has no effect (if the <remove> tag is first, then the <add> tag will just
    add the module back in).

    The purpose of the custom error module is for users to be able to create and
    deploy custom error page (e.g. for 404 or 500 or similar). AFAIK WSUS
    doesn't use any of those for it's dedicated site - so this module should
    have no effect. If you are running WSUS out of the Default Web Site *and*
    you also deploy your own custom error pages *then* this may cause an issue
    (because your custom error pages will be sent back to the client rather than
    IIS default error pages). The solution here is to ensure that your custom
    error pages are only sent back for requests to folders in the Default Web
    Site that you have your own custom apps in, and not for the folders that
    WSUS is running out of.

    Ken Schaefer, May 12, 2008
  5. Remember... Microsoft dev teams develop applications in a "Vaccum
    Mentality"... they assume that nothing else will be running on their server.

    Ironically, for all of Steve and Ozzie's latest in "interoperablity", you'd
    think they'd start with "interoperability" in house!

    The instructions, as written, are to /replace/ the <add> tag with the
    <remove> tag, but your point is noted -- having both tags will result in
    only the second element being applied.

    All of which is =moot= in WSUS 3.0 because there is *no* browsable or
    interactive web content in WSUS 3.0.

    It would have been relevant to http://wsus/WSUSAdmin on WSUS 2.0, which has
    a web interface but then we'd not be installing WSUS 2.0 on Win2008 anywayz.

    Lawrence Garvin, M.S., MCITP, MCBMSP, MCTS(x4), MCP
    Senior Data Architect, APQC, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2008)

    MS WSUS Website:
    My Websites:;
    My MVP Profile:
    Lawrence Garvin [MVP], May 13, 2008
  6. Bruce Sanderson

    Ken Schaefer Guest

    Yes - but your custom error pages will be returned to clients making HTTP
    requests. Your custom error pages may not return the HTTP status that would
    make the client think there is an error (e.g. a lot of custom 404 error
    pages return a 200 OK HTTP status).

    Nothing to do with whether the content is browsable or not.

    Ken Schaefer, May 13, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.