Microsoft have just released there Remote connectivity Analyzer tool this allows you to perform testing of your Exchange 2007 services remotely from a web page ! awesome hey
Allows you test ActiveSync, Autodiscovery, Outlook Anywhere connectivity and inbound mail too. Very useful for testing your configuration is setup correctly but can also be used for testing after maintenance has been performed on Exchange to confirm it's all working correctly etc
https://www.testexchangeconnectivity.com/
More information can be found here : http://msexchangeteam.com/archive/2009/03/25/450908.aspx
Enjoy !
Wayne Hollomby
Friday, 27 March 2009
Xobni leaves beta and launches finally!
After almost one year of beta testing, Xobni has launched Xobni 1.7, which is the first version without the beta label. v1.7 dramatically improves the performance and reliability of Xobni with the following improvements:
- Outlook now starts 31% faster
- Xobni Profiles now load 42% faster
- Users can control how often and how much data xobni indexes
- Users can control when Xobni is running
If you've got Xobni installed (I do and it's still very useful and effective) then you need to run their installer to receive the latest release http://www.xobni.com/download
Tuesday, 24 March 2009
Exchange 2003 OWA, Exchange 2007 OWA and Internet Explorer 8
Currently no real issues to report. All seems to be working perfectly. You may have IE Topbar prompts if using a Self Signed Cert - not a problem though for 99% of Hosters.
Oliver Moazzezi
MVP - Exchange Server
Oliver Moazzezi
MVP - Exchange Server
Friday, 20 March 2009
Update Roll-up 7 for Exchange Server 2007 Service Pack 1 has been released.
RU7 for SP1 is out:
http://msexchangeteam.com/archive/2009/03/18/450863.aspx
Some of the most important fixes are listed below (taken from above Exchange Team post):
First off, we fixed the SCR issue which have caused everyone some pain and which did not get completed in time to be included in the last update roll-up.KB 961281 Update Roll-up 5 for Exchange Server 2007 Service Pack 1 introduced an issue where you receive an error when attempting to enable SCR on a storage group if the environment has a parent domain -> child domain active directory structure. Tim has blogged about this over here. This is now fixed. Additionally, there are also 2 other SCR related issues which we have been addressed in this roll-up and have been asked for by many customers.KB 957834 Network shares are deleted and created intermittently by the replication service on an Exchange SCC cluster when SCR is enabled on the Exchange server
KB 958331 Restore-StorageGroupCopy command may fail in an Exchange Server 2007 SCR environment.
We have also fixed two issues which caused intermittent crashes in the IMAP4 service and resulted in event 4999 being logged in the event logs. The following KBs have more information on the scenarios which are fixed: KB 957504 and KB 960292.
Oliver Moazzezi
MVP - Exchange Server
http://msexchangeteam.com/archive/2009/03/18/450863.aspx
Some of the most important fixes are listed below (taken from above Exchange Team post):
First off, we fixed the SCR issue which have caused everyone some pain and which did not get completed in time to be included in the last update roll-up.KB 961281 Update Roll-up 5 for Exchange Server 2007 Service Pack 1 introduced an issue where you receive an error when attempting to enable SCR on a storage group if the environment has a parent domain -> child domain active directory structure. Tim has blogged about this over here. This is now fixed. Additionally, there are also 2 other SCR related issues which we have been addressed in this roll-up and have been asked for by many customers.KB 957834 Network shares are deleted and created intermittently by the replication service on an Exchange SCC cluster when SCR is enabled on the Exchange server
KB 958331 Restore-StorageGroupCopy command may fail in an Exchange Server 2007 SCR environment.
We have also fixed two issues which caused intermittent crashes in the IMAP4 service and resulted in event 4999 being logged in the event logs. The following KBs have more information on the scenarios which are fixed: KB 957504 and KB 960292.
Oliver Moazzezi
MVP - Exchange Server
Thursday, 19 March 2009
Hosted Exchange prior to RPC over HTTPs / Outlook Anywhere
Back when hosting Exchange 2000 and 2003 RTM an Exchange Hoster had limited options when opening up MAPI to their client base. The options basically were:
1. Require the customer to use a VPN, do not use Static MAPI ports
2. Require the customer to use a VPN, use Static MAPI ports
3. Have MAPI open over the Internet, use Static MAPI ports, directly NAT to Exchange Server
4. Have MAPI open over the Internet, use Static MAPI ports, NAT but filter traffic to Exchange Server
1. Is a fairly simple affair. However I found customers didn’t like the addition of having to setup a VPN across their desktops and remember to login to it.
2. Again this achieved nothing more than option 1
3. This was the easiest way to connect, however it totally opened up Exchange Servers to the Internet. Seeing Outlook queries Exchange initially using RPC (Port 135) you would be open to worm attacks like the famous Blaster Virus
4. The same as the above, but hopefully with better protection in protecting against attacks, virii or worms.
3 and 4 also opened up issues with customers connecting to Exchange Hosters. When the Blaster virus took hold Networks across the World were locking down Port 135 on their networks to try and stop machine infection. This caused a lot of issues unless you had a VPN option in place for customers.
My preferred method of access is RPC over HTTPs (Introduced in Exchange 2003 Server SP1, known as Outlook Anywhere in Exchange 2007 RTM/SP1). This requires Outlook 2003 as a minimum to work. This in certain circumstances can cause more overhead for an Exchange platform to the traditional MAPI protocol. However it certainly has its benefits.
Outlook Anyhwere (I will refer to this for both Exchange 2003 and 2007 from here on) allows the encapsulation of RPC over SSL. You receive your MAPI connection by using the RPC Proxy Service (usually installed on an Exchange Front End) and connecting to your OWA url.
I advise this as the best way to connect to Exchange over the Internet. Simplifying connection for users and allowing a more secure Exchange platform for an Exchange Hoster.
References
“Exchange Server static port mappings” http://support.microsoft.com/kb/270836
“Overview of Outlook Anywhere” http://technet.microsoft.com/en-us/library/bb123741.aspx
“How to configure RPC over HTTP in Exchange Server 2003” http://support.microsoft.com/kb/833401
Oliver Moazzezi
MVP - Exchange Server
1. Require the customer to use a VPN, do not use Static MAPI ports
2. Require the customer to use a VPN, use Static MAPI ports
3. Have MAPI open over the Internet, use Static MAPI ports, directly NAT to Exchange Server
4. Have MAPI open over the Internet, use Static MAPI ports, NAT but filter traffic to Exchange Server
1. Is a fairly simple affair. However I found customers didn’t like the addition of having to setup a VPN across their desktops and remember to login to it.
2. Again this achieved nothing more than option 1
3. This was the easiest way to connect, however it totally opened up Exchange Servers to the Internet. Seeing Outlook queries Exchange initially using RPC (Port 135) you would be open to worm attacks like the famous Blaster Virus
4. The same as the above, but hopefully with better protection in protecting against attacks, virii or worms.
3 and 4 also opened up issues with customers connecting to Exchange Hosters. When the Blaster virus took hold Networks across the World were locking down Port 135 on their networks to try and stop machine infection. This caused a lot of issues unless you had a VPN option in place for customers.
My preferred method of access is RPC over HTTPs (Introduced in Exchange 2003 Server SP1, known as Outlook Anywhere in Exchange 2007 RTM/SP1). This requires Outlook 2003 as a minimum to work. This in certain circumstances can cause more overhead for an Exchange platform to the traditional MAPI protocol. However it certainly has its benefits.
Outlook Anyhwere (I will refer to this for both Exchange 2003 and 2007 from here on) allows the encapsulation of RPC over SSL. You receive your MAPI connection by using the RPC Proxy Service (usually installed on an Exchange Front End) and connecting to your OWA url.
I advise this as the best way to connect to Exchange over the Internet. Simplifying connection for users and allowing a more secure Exchange platform for an Exchange Hoster.
References
“Exchange Server static port mappings” http://support.microsoft.com/kb/270836
“Overview of Outlook Anywhere” http://technet.microsoft.com/en-us/library/bb123741.aspx
“How to configure RPC over HTTP in Exchange Server 2003” http://support.microsoft.com/kb/833401
Oliver Moazzezi
MVP - Exchange Server
Subscribe to:
Posts (Atom)