Outlook Web access is a fantastic tool for our company, providing on-the-go access to people's mailboxes - which is of course secured by SSL and uses Forms Based Authentication. Internally, we have an intranet portal that allows us to access the various systems - one of which is OWA. One of the stipulations for this internal portal is that it is all Single Sign On using NTLM authentication - integrated authentication. This is where the problem lies because enabling OWA with Forms Based Authentication over SSL disables Integrated Authentication. So our choice is to have users enter their credentials twice (not acceptable) or to disable FBA and have external users log on with the annoying pop-up.

OR...

You can create a copy of the /Exchange and /Public Virtual Directories and configure them to use Integrated Authentication. You can also restrict access to them by IP...here's how:

 I'm assuming you've already set up OWA with SSL on your Exchange server. If you need to do that, try How do I configure OWA to use SSL? at Daniel Petri's site

1. Log onto your Exchange Server, and open up the IIS control panel. Locate your /Exchange and /Public virtual directories.
2. Right click /Exchange, select "All Tasks" and then "Save Configuration to a File..."
   
3. Go through the dialogue, save to a file and if you're worried about security, add a password.
4. Once you're done, right click any white space in the root web site (or the exchange web site) and select "New", then select "Virtual Directory (from file)..."
   
5. You will be presented with the "Import Configuratio" dialogue, click "Browse..." and select the file you've just created. Click "Read File" and select the Exchange location underneath
   
6. Click "OK" and you'll be asked to provide a new name, or replace the existing Virtual Directory - select create a new one and put an appropriate name (I uses ExchangeIA)
   
7. Now, this step is optional, but read on anyway because you might want to think about it. I only want to allow people on my network to access this using Integrated Authentication, no one else, so I am going to restrict access to the Virtual Directory that I've just created to my IP subnet. To do this right click the newly created Virtual Directory (ExchangeIA) and select the "Directory Security" tab. Under "IP address and domain name restrictions" click "Edit". Now select "Denied access" to deny anyone other than the exceptions, then click "Add.." and enter the details of your network to allow those computers access.
   
8. Now head back to step 1 and repeat for the /Public folder, if Integrated Authentication is required for Public Folders.
   

We were integrating a 3rd party product's web parts with MOSS the other day and came accross an interesting problem. In site editing mode, all the drop down menus would appear for a flash and then go blank. The actual admin pages we were trying to get to would work if you entered them into the browser directly, but that isn't an easy way to manage the site!

The problem turned out to be that in the process of getting the 3rd party web parts to work, the support team had added a MIME type to the IIS installation.

This is obviously not what you'd do in a production environment, but the support team put it in to rule out the MIME type in the integration problems. Once the rogue "catch all" MIME type was changed to a more specific extension, and of course the arbitrary IISReset.exe was performed, the menu's came back to life.

The relating MS KB article is support.microsoft.com/kb/939311/en-us

If you've logged onto the properties for your IIS install and found that the ASP.NET tab has mysteriously disappered, you can try a couple of things.

Firstly, try re-registering ASP.NET with IIS using the ASPNET_REGIIS.exe located in the .NET installation folder:

Chances are though, that it won't work, and that you can try and number of command using aspnet_regiis.exe or even uninstalling and reinstalling .NET and you won't actually fix the problem. (Note: on x64 systems this could be a different problem, Google again with x64!)

This was solved by switching a flag (Enable32BitAppOnWin64) to false in the IIS metabase:

You should then be able to see the ASP.NET tab restored in the site properties.