IISRESET Error

The short answer is "yes" for most activities you'll carry out via STSADM against SQL databases.

For the overwhelming majority of STSADM commands that execute against the SharePoint API directly (rather than scheduling tasks to carry out an action), the security context within which commands are executed is yours -- the signed-in user. As you've seen in the example you cited, your user account context is the one that will be used for the retraction. If you don't have the appropriate rights in SQL to carry out the operation it will fail (as you've seen).

This contrasts with most activities you'll carry out through the UI (that is, Central Admin). In the example you cited, retracting the solution via Central Admin would result in the command being executed within the context of the farm service account, as that account is the application pool identity for the Central Admin site. Result: the retraction would succeed even though you (personally) don't have permissions to the associated database.

If your environment is setup such that your account doesn't have admin-level access to the databases within the SharePoint farm, I would recommend carrying out as many activities as possible through the UI to avoid the type of security context issues you're encountering. You'll find you can do most of what you need to do that way. One notable exception that comes to mind, though, is adding a solution (STSADM -o addsolution) to the farm solution store -- no UI counterpart to the STSADM command exists.

Alternatively, you could do something similar to what MadlyAlive suggested (i.e., logging in with the farm service account) ... though local admin access for the farm service account is neither required nor recommended by Microsoft. You could also have your account granted the minimal set of permissions inside of SQL Server needed to carry out your operations.

For more discussion, see Microsoft's KB article at http://support.microsoft.com/kb/896148.

Rule of thumb recap: STSADM uses your account context, Central Admin uses the farm service account context.

I hope this helps!

The key thing to do if at all possible (and it sounds possible for you) is to use a dedicated IP per site. Then you don't need to mess with host headers for SSL. The host headers in IIS Manager are just for HTTP and not for HTTPS. While SSL and host headers are possible to do using adsutil (and other conditions are met), it's not preferred if you have 2 IPs available to you.

So, with 2 IPs at your disposal, just set HTTP and HTTPS to use 10.0.0.3 for OWA and 10.0.0.6 for SharePoint. Make sure to set both HTTP and HTTPS on each site.

Since you got a directory listing denied, which is not what you expected, it's possible that when you made your last change there were duplicate bindings on your Sharepoint site, causing the site to stop. If that occurred, then likely a 3rd site is picking up the sharepoint site now.

To sum up: - set unique IPs per site, make sure that they are set for http and https both - make sure that the sharepoint site is started right now - try the 'break' test. Turn off the sharepoint site for a minute for testing and if you get a different type of message then you know that the bindings are correct, which would mean that something unrelated to the bindings is wrong with the site.