We'd love to get a copy of your installer logs before the OS deletes them, so that we can figure out why your install didn't setup ARR the first time. They are in c:/users/[username]/AppData/Local/Temp/2/MSI####.txt

If you can grab those and send them in a support ticket with a link to this thread, it will help us solve the issue for others.

Regarding bindings, HTTP is required for each of those hostnames you want to use, (or just an IP binding that they all resolve to). If you use auto-generated certificates within SmarterMail itself, it should hook the IIS site bindings automatically to IIS.  

As to bindings and hostnames though, essentially you're going to set things up the same way you would normally minus generating certificates and adding HTTPS bindings because SmarterMail will now handle that assuming all the other pieces are in place. You'll still need to: 

1. Add A records for all desired hostnames. This should include mail.customer-domain.com, autodiscover.customer-domain.com, etc. 

2. Add HTTP bindings for all desired hostnames and verify they work from the server and the internet. Verify the customer domain is NOT configured to redirect to HTTPS within SmarterMail at least until SSL is complete. 

3. Configure SmarterMail and the IIS Centralized Certificate Store directory to reference the correct/newly created certificates folder. This is in C:\SmarterMail\Certificates by default, and you just want to make sure SmarterMail, IIS, and the certificate storage itself is all in the same place. 

3. Let SmarterMail generate certificates and add HTTPS bindings, then enable the Force all traffic over HTTPS toggle for the customer domain in SmarterMail. 

The PFX/certificate you define in Settings>Bindings>Ports will serve as a fallback certificate if a better certificate isn't found (based on requested hostname) in your certificates directory as defined in SmarterMail/IIS, so you won't need specific port entries for all of the certificates. I hope that helps!