In IIS, a binding consists of an IP address, a port, and a host header on which the web server listens for requests made to that website. The binding tells IIS how to route inbound HTTP/HTTPS requests.
In this recipe, you create a new website on SRV1 and add bindings to enable the site. In this recipe, you only bind for HTTP.
You need to run this recipe on SRV1 after installing IIS (which you did in the Installing IIS recipe).
- Import the
WebAdministrationmodule:Import-Module -Name WebAdministration
- Create and populate a new page:
$SitePath = 'C:inetpubwww2' New-Item $SitePath -ItemType Directory | Out-Null $page = @' <!DOCTYPE html> <html> <head><title>Main Page for WWW2.Reskit.Org</title></head> <body><p><center> <b>HOME PAGE FOR WWW2.RESKIT.ORG</b></p> This is the root page for this site </body></html> '@ $PAGE | Out-File -FilePath $SitePathINDEX.HTML | Out-Null
- Create a new website that uses host headers:
$WSHT = @{ PhysicalPath = $SitePath Name = 'WWW2' HostHeader = 'WWW2.Reskit.Org' } New-Website @WSHT - Create a DNS record on
DC1forWWW2.Reskit.Org:Invoke-Command -Computer DC1.Reskit.Org -ScriptBlock { $DNSHT = @{ ZoneName = 'Reskit.Org' Name = 'www2' IpAddress = '10.10.10.50' } Add-DnsServerResourceRecordA @DNSHT } - Finally, show the site, as follows:
$IE = New-Object -ComObject InterNetExplorer.Application $URL = 'Http://WWW2.Reskit.Org' $IE.Navigate2($URL) $IE.Visible = $true
In step 1, you import the WebAdministration module explicitly, in order to load the IIS provider. In step 2, you create a new page on SRV1 that serves as the new site's home page. These two steps produce no output.
In step 3, you create a new IIS website on SRV1; namely, WWW2.Reskit.Org. The output of this step looks like this:
In step 4, you create a new DNS record to point to this new site, which produces no output. In step 5, you use Internet Explorer to navigate to the new site, which looks like this:
By default, while you can have as many HTTP-based sites as you want on a given machine, you can only have one HTTPS site. This is because the details of the site that the browser is asking for are inside the encrypted content, and thus, can only be actioned once decrypted.
To overcome this limitation, IIS uses a TLS feature known as Server Name Indication (SNI). SNI allows the name of the hostname being contacted to be specified during the SSL/TLS handshake. This, in turn, enables IIS to support more than one secure site. To use SNI, the browser or web client, as well as the web server, must support SNI. Modern web browsers support SNI, which has been a feature of IIS on Windows Server for many versions.
In step 4, you created a DNS A record that points to the site at 10.10.10.50. If your site is on a different IP address, change this input accordingly.
SNI has been a feature of IIS for some time. See https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability for details of the SNI feature in IIS in Windows Server. You can find more details on SNI in general at http://en.wikipedia.org/wiki/Server_Name_Indication.