In order to supply the necessary information in the block and select the correct bitness, you need to gather some information for the site that you are setting up.  This can all be done from the IIS manager (the tool used to configure IIS.    

Gathering Information

Specifically, you need to know for a given site:

1. The site binding (what name and ports and protocol it is using)
2. The internally assigned "Site Id" that's being used for the site.
3. The application pool that the site is using.
4. The setting on the application pool then determines if you want a 32bit or 64bit download.  

Please see Windows IIS Information Gathering for Shibboleth configuration (PDF) for guidance on how to locate this information.

Adding the InProcess code block

This code sample is from the original Shibboleth example file; it was removed from the campus-specific shibboleth2.xml file but should be added back in for IIS server use.  The bolded information in the <Site> tag is gathered in the steps shown in the attachment.   

If you wish to Shibboleth-enable multiple sites served off the same server, the <Site> tag can be repeated with additional information.  Additional sites will also need to be registered with the IDP. 

   <!--

    The   InProcess section contains settings affecting web server modules.

    Required   for IIS, but can be removed when using other web servers.

    -->

      <InProcess logger="native.logger">

          <ISAPI normalizeRequest="true"   safeHeaderNames="true">

              <!--

              Maps IIS Instance ID values to the host scheme/name/port.   The name is

              required so that the proper <Host> in the request   map above is found without

              having to cover every possible DNS/IP combination the user   might enter.

              -->

              <Site id="2"   name="name.domain.illinois.edu"   scheme="https" port="443"/>

              <!--

              When the port and scheme are omitted, the HTTP request's   port and scheme are used.

              If these are wrong because of virtualization, they can be   explicitly set here to

              ensure proper redirect generation. -->

          </ISAPI>

      </InProcess>

 Adding the RequestMapper block

Next, IIS also needs the <RequestMapper> block.  This is also an example that was removed from the campus-specific shibboleth2.xml file that should be added for IIS use.

In the code example below:

• 'Host name' needs to match your web server name.   
• 'Path name="secure"' means a directory named "secure" at the top-level of that site needs protection.  (You can change this directory name as needed.) Accessing anything inside that directory will cause authentication to happen first.   
• The second example commented out protects an entire site. 

    <RequestMapper type="Native">

          <RequestMap>

              <!--

              The example requires a session for documents in /secure on   the containing host with http and

              https on the default ports. Note that the name and port in   the <Host> elements MUST match

              Apache's ServerName and Port directives or the IIS Site   name in the <ISAPI> element above.

              -->

              <Host name="name.domain.illinois.edu">

                  <Path name="secure" authType="shibboleth"   requireSession="true"/>

              </Host>

              <!-- Example of a second vhost mapped to a different   applicationId. -->

              <!--

              <Host name="admin.example.org"   applicationId="admin" authType="shibboleth"   requireSession="true"/>

              -->

          </RequestMap>

      </RequestMapper>

Next steps

After adding these code samples back to shibboleth2.xml, continue with your choice of one of the three specific configurations (Urbana-specific, University of Illinois-specific, or multi-university) described in step 6b of Shibboleth, Setting up a Service Provider.