RSS Subscription 168 Posts and 2,769 Comments

Archive for July, 2009

Exchange UM – Disabling Missed Call Notifications

There’s two ways to disable Missed Call Notifications:

  • At the UM Mailbox Policy
  • On a UMMailbox

When viewing an existing UM Mailbox Policy, you will see the “Allow Missed Call Notifications” option which is enabled by default.

Disabling this option in Exchange 2007 does nothing as there is currently a bug in Exchange 2007 that prevents this from working.  According to a Microsoft employee I talked with, this bug is postponed and is fixed in Exchange 2010 and does not believe this will be fixed in Exchange 2007. You never know though.  It may end up being fixed.

The alternative is to excplicitly disable this for UM enabled users.

If you run the following command, you can disable the option for a specific user:

Set-UMMailbox User -AllowMissedCallNotificationEnabled $false

Of course you can also use piping so you can get all UM Mailbox Users and disable it in bulk. For example:

Get-UMMailbox | Set-UMMailbox -AllowMissedCallNotificationEnabled $false

Share

Exchange 2007 OWA via ISA RSA – Authentication Delegation

When utilizing ISA (in this case, ISA 2006) to publish Outlook Web Access (OWA), there are various options you can choose from in order to authenticate a user.  One listener authentication mechanism that is often used is Forms Based Authentication.  By default, your ISA form when publishing OWA will look like the following:

As you can see, by default, it asks you for Domain\User name.  By going into the listener authentication options, you can specify the default domain that should be specified if the user does not specify a domain.  Without specifying this, if the user were to only enter their user name, authentication would fail as it is not passing the domain back to Exchange. By going into the properties of your OWA listener, you will see an Authentication tab.

Because we will be utilizing RSA, we will choose RSA as the method of Authentication utilizing Forms Based.  Because Exchange isn’t set to also authenticate to RSA (only ISA), we will need to collect additional information in the form.  This allows a user to also enter their AD credentials so after ISA authenticates a user, ISA can still pass back the AD credentials back to Exchange as the Authentication Delegation mechanism using Basic.  Selecting to Collect dditional delegation credentials in the form allows you to utilize either Basic, NTLM, or Negotiate as an Authentication Delegation mechanism.

By clicking on Advanced, we can see the section in which we can configure the domain to automatically pass back to Exchange during the Authentication Delegation.  Again, a user authenticates from a browser to a web listener and from there, ISA then takes certain information about the user and passes that back to Exchange which is the Authentication Delegation piece.

But, as you can see, the Domain name piece is greyed out.  But if you look at the authentication form for ISA when RSA is enabled, you can see it doesn’t ask for the Domain Name.

Now because of this, if a user doesn’t specify to use a different user name which does allow you to enter a domain\username, the authentication delegation piece will fail as the basic authentication mechanism that you will set on Exchange will want a domain\username passed back.  So if we can’t set this in ISA, how do we set it?  Well, we can actually configure IIS to automatically assume a specific domain to be used if no domain is specified.  While IIS6 and IIS7 are very much different, you can actually utilize the Exchange Management Console to set this option which will stamp IIS appropriately (both IIS6 and IIS7.)

The default authentication option for OWA on a CAS is to use Forms Based Authentication and require a user to specify their domain.

If you specify the following option, choose your domain, and click Apply, it will stamp IIS to assume the specified domain name.  A user can still specify their domain or not specify it and both will work when authenticating.  This should hopefully make you realize that if ISA relays authentication back to IIS on the CAS, that it won’t matter anymore if the domain is specified or not.

But because our ISA Authentication Delegation for our OWA rule will utilize Basic Authentication, we now want to specify Basic Authentication within Exchange for OWA.  But don’t worry, even if you change it from the previous setting of Forms Based Authentication with the assumed domain, IIS will still stay stamped properly. So go ahead and choose Basic.  You will be prompted to do an IISReset -Noforce.  Go ahead and do it after choosing Basic.

So back over to ISA, if we go into our Outlook Rule, we can see the Authentication Delegation set to Basic which it will need to be since that’s what the Authentication option is set to for OWA on our CAS.

So taking everything into account what we did above, what happens is the user authenticates to ISA utilizing a form and specifies their username without the domain, RSA key, and password for their username.  When they click Log On to authenticate, ISA will authenticate the user with RSA, and when that passes, ISA will utilize basic authentication due to the authentication delegation being set to basic to pass the username and password they specified (with no domain) back to OWA. Because IIS is stamped to automatically utilize the domain even if it wasn’t specified, authentication will work and the user will be logged into OWA.

Share