Using IIS::Ensure-Site without removing bindings?

[Justinvolved]

Hello,

I'm using IIS::Ensure-Site to create an IIS site for an applicaiton if it does not exist. When creating the site I would like to add only a http binding on port 80. I'm using WinACME which wil scan all IIS sites and add https 443 binding accordingly.

The problem I have now is that when re-running the deployment IIS::Ensure-Site will remove all bindings other than the one I have specified in IIS::Ensure-Site.

Is it possible to specify that IIS::Ensure-Site should check if the site exists with that binding, but then leaves additional bindings intact?

Thanks,
Justin

[atripp]

Hi @Justinvolved ,

What properties are you setting?

If you run Ensure-Site with the Bindings property, it will:

• update the properties of the bindings specified if needed
• delete the bindings not specified
• add the ones that don't exist

Note that you can specify a list of bindings in that property, so you could do this:

IIS::Ensure-Site test
(
    Path: E:\wwwroot\test,
    AppPool: testPool,
    Bindings: @(
        %(IPAddress: *, Port: 80, HostName: test.domain.local, Protocol: http),
        %(IPAddress: *, Port: 443, HostName: test.domain.local, Protocol: https),
     )
);

Thanks,
Alana

[Justinvolved]

Hi @atripp,

I'm using %(IPAddress: *, Port: 80, HostName: test.domain.local, Protocol: http) as a binding indeed.

I just noticed that this way of adding bindings is actually consideren legacy. So I will switch to using IIS::Ensure Site Binding instead, and wil just make sure all the bindings are there.

It might be an idea to add to the documentation the behaviour you described, for me it wasn't clear the operation would also remove bindings (I had Transfer Files in mind where a delete operation is explicitly set by parameter), but since it is a legacy feature that might be moot :-)

Thanks,

Justin

[atripp]

Hi @Justinvolved ,

Ah yes, getting all this modeling done sensibly is a challenge, and documenting it is a whole new pain

The main issue we're facing is that you can't create a Site in IIS without a binding; the API will simply reject it and error. This means that if you use IIS::Ensure-Site to create a site, but don't specify a binding, it will error. However IIS::Ensure-Site can update a site no problem.

This is why we originally created the Bindings property. However, it's a but challenging to use, and exhibits the behavior you describe: it "ensures" that list matches whatever is in the Site.

Our current way of thinking is this:

IIS::Ensure-Site MySite
(
    AppPool: MyPool,
    Path: C:\Websites\MySite,
    BindingProtocol: http,
    BindingHostName: app.local,
    BindingPort: 80
);

IIS::Ensure-SiteBinding
(
    Site: MySite,
    Protocol: https,
   ... ssl properties ...
);

Our "new" way of thinking is that it might make sense to allow IIS::Ensure-Site to have two sets of binding properties.

IIS::Ensure-Site MySite
(
    AppPool: MyPool,
    Path: C:\Websites\MySite,
    HttpHostName: app.local,
    HttpBindingPort: 80,
    HttpsBindingPort: 443,
    HttpsCertificateOrWhatever...
);

This seems to align with how most people want to set up a site in IIS (i.e. two bindings).

Definitely open to your feedback

Cheers,
Alana