Part 1 of this two-part series on how to redirect OWA users to the right site and protocol discussed the issues involved with creating redirects for users who enter incorrect URLs or incorrect protocols when accessing the OWA Web site. We also went over the initial configuration steps you can use to perform the redirects. In this, part 2 and final part of the series, we’ll go over the configuration steps from beginning to end and explain the rationale behind the steps. By the time you finish the procedure, users will be able to enter incorrect paths and incorrect protocols and still be redirected to the correct OWA Web site. The end result is fewer Help Desk calls.
What could be worse than facing a seriously corrupted mailbox store? Yes you guessed right – facing a completely dead Exchange Server. In this article I’ll shine some light on the steps necessary in order to restore an Exchange 2003 Member Server, that has experienced a major hardware failure causing a complete loss of data.
There are several steps you will have to do if you have to restore your Exchange Server 2003 System to alternate hardware. This is very often a task if your old Exchange Server box crashed and you did not have a chance to get the same or very similar hardware back. The goal now will be restoring your Exchange Server 2003 System on new hardware that is not the same as the old. Within this article we will get a drill-down on how this works and what steps and tasks need to be done to make things run properly.
Microsoft Product Support Services (PSS) can provide you with a useful tool called NoMAS. In this article I want to cover what the NoMAS tool is and under what circumstances you might want to use it.
A frequent request I see on the ISAServer.org Web boards and mailing lists is for information on how to help hapless uses who can’t remember to enter the correct path or protocol to reach the Exchange Server’s OWA site. While it might seem like a simple issue to enter the path https://owa.domain.com/exchange into the Web browser Address bar and press ENTER, long experience tells us that this isn’t the case.
These days almost every corporate e-mail has a disclaimer. Companies use them because of legal issues, as an advertising means or maybe because they think messages look nicer with a disclaimer. Since Exchange Server 5.5 Microsoft has provided a way of adding basic disclaimers to outgoing messages. Let’s see how things have evolved since then and what we can do to extend the provided capabilities.
Issuing certificates has historically been a fairly complicated process
requiring the installation of Certificate Services, but a less
well-known utility from the IIS6 Resource Kit Tools known as SelfSSL can
make the process a lot easier.
Featured Links*
Receive all the latest articles by email!
Receive Real-Time & Monthly MSExchange.org article updates in your mailbox. Enter your email below! Click for Real-Time sample & Monthly sample
Become an MSExchange.org member!
Discuss your Exchange Server issues with thousands of other Exchange experts. Click here to join!