I would add that in an Exchange 2003/Windows 2003/Outlook 2003 environment, buffer packing can come into play which tends to reduce overall network traffic. CliNetTraf.doc, on the microsoft downloads site, goes into network requirements in detail and how they are affected by various versions of these pieces of software. -----Original Message----- From: Mulnick, Al [mailto:Al.Mulnick@xxxxxxxxxx] Sent: Wednesday, September 15, 2004 11:55 AM To: [ExchangeList] Subject: [exchangelist] RE: Migration advice desired http://www.MSExchange.org/ I'm going to assume 29 servers vs. 21 else there's a quizzical look on my face as I type this ;) Greg, RPC/HTTP is not designed to save bandwidth. If anything, since it encapsulates RPC it could be more traffic. The saving grace is that it's HTTP(S) and therefore can be sent into networks via well-known entry ways. It's possible that it could be less, but not likely. Cached mode is designed to produce a better user experience only. It is not designed to save bandwidth nor prevent network traffic. If anything, it has the potential to produce more traffic since you have to download every message regardless of wanting it or not. Online mode doesn't have to download every message, but rather the header information is displayed to the client (depending on the view chosen by the client; by default it's going to download every message you look at since it puts it in that crazy view pane). The trick to putting Outlook across a WAN is to know what your AVAILABLE bandwidth is vs. your total possible as well as figuring out how to make the servers faster than the requests so that when a request comes in, there is as little wait time at the server to service the request as possible. That means you have a lower total roundtrip for request/response and your client gets a better experience in terms of performance. In your case, cached mode/RPC/HTTP(S) might be helpful if the clients are allowed to use an internet connection to the server and are not restricted/crowded on that internet connection (obviously it's an ecosystem so your Exchange server network has to have enough bandwidth as well). My advice? I'd check with the network folks and find out available, peak, and average bandwidth utilization today and try to project what my usage scenarios are going to be. I'm not one who likes to deploy servers in a decentralized manner for control purposes, so I would want to do everything I could to get to your end goal of 5 servers in hub sites. Saying that, I've done just that, but you have to do your homework. Feel free to ping me off-line if you have any questions I can help with. Al -----Original Message----- From: Lara, Greg [mailto:GLara@xxxxxxx] Sent: Tuesday, September 14, 2004 11:33 AM To: [ExchangeList] Subject: [exchangelist] Migration advice desired http://www.MSExchange.org/ I've been in the planning stages of a migration project (Exchange 5.5 to 2003) for quite a while now. I've thought a lot about my org's infrastructure and have produced detailed plans and diagrams explaining the whys and wherefores for my boss and co-workers. There's some reticence being expressed at the viability of the plan, so I wanted to run it by some of my peers. In summary, we've got 21 Exchange servers, distributed amongst 29 sites, that support about 500 users. The WAN consists of a point-to-point VPN connected over full T1's and broadband (minimum bandwidth of 768k). All clients are running Outlook 2002 in MAPI mode. The plan is to consolidate those 21 5.5 servers into 5 2003 servers, which will be placed in regionally central "hub" sites. Clients in sites that currently don't have an Exchange server connect to their server over the WAN; clients that will be losing a server will do the same. The average number of clients on the consolidated hub servers will be about 85, with anywhere from 40 to 70 of those clients located at remote sites. The concern is that client "performance" will be significantly diminished, particularly for those losing a local server. Clients that currently connect to remote servers sometimes experience delays, the source of which aren't not always easy to diagnose. There is also a concern that the T1 at the hub sites won't be adequate for both local use in addition to VPN and Outlook client traffic. I agree and feel that may need to go with multiplexed T1s in those locations. I know of companies who have consolidated hundreds of users into single remote servers, but they tend to have huge pipes that can accommodate the extra traffic. So, the big questions are: Will we save on client access bandwidth by using RPC over HTTP? Does anyone reading this have experience with remote client access over WAN links? If so, can you offer feedback on the client experience? Any other thoughts or suggestions? Thanks all. Greg Lara ------------------------------------------------------------------------ ---- --------------------------- This e-mail message may contain privileged, confidential and/or proprietary information intended only for the person(s) named. If you are not the intended recipient, please destroy this message, and any attachments, and notify the sender by return e-mail. If you are not the intended recipient(s), or the employee or agent responsible for delivering the message to the intended recipient(s), you are hereby notified that any dissemination, disclosure or copying of this communication is strictly prohibited. ------------------------------------------------------------------------ ---- --------------------------- -----Original Message----- From: Periyasamy, Raj [mailto:Raj.Periyasamy@xxxxxxxxxxxx] Sent: Tuesday, September 14, 2004 9:07 AM To: [ExchangeList] Subject: [exchangelist] RE: RPC over HTTPS and Outlook 2003 http://www.MSExchange.org/ Mustafa, I hope you have configured your Outlook correctly for RPC Over HTTP. Before you test the RPC over HTTP across the firewall, try to test it within the LAN. Follow the steps below to create the profile, and test this configuration in LAN. Make sure the Outlook is using only HTTPS and not TCP/IP to connect to Exchange server. You can check this by Control+right clicking on the Outlook icon in the task bar, and selecting Connection status. Let me know if this works first before proceeding further. On the Exchange Server Settings page, do the following steps: a. In the Microsoft Exchange Server box, type the name of your back-end Exchange server where your mailbox resides. b. Select the check box next to Use Cached Exchange Mode (optional, recommended). c. In the User Name box, type the user name. d. Click More Settings. e. On the Connection tab, in the Exchange over the Internet pane, select the Connect to my Exchange mailbox using HTTP check box. f. Click Exchange Proxy Settings. On the Exchange Proxy Settings page, under Connections Settings, do the following steps: a. Enter the fully qualified domain name (FQDN) of the RPC proxy server in the Use this URL to connect to my proxy server for Exchange box. b. Select the Connect using SSL only check box. c. Next, select the Mutually authenticate the session when connecting with SSL check box. d. Enter the FQDN of the RPC proxy server in the Principle name for proxy server box. Use the format: msstd:FQDN of RPC Proxy Server. e. As an optional step, you can configure Outlook 2003 to connect to your Exchange server using RPC over HTTP by default by selecting the check box next to On fast networks, connect to Exchange using HTTP first, then connect using TCP/IP. Regards, Raj -----Original Message----- From: Mustafa Cicek [mailto:mbcicek@xxxxxxxxx] Sent: Tuesday, September 14, 2004 9:36 AM To: [ExchangeList] Subject: [exchangelist] RPC over HTTPS and Outlook 2003 http://www.MSExchange.org/ Hi! I think, I configured all (on server and client) for RPC over HTTPS correctly. Unfortunately, Outlook 2003 cannot connect to my Exchange Server 2003. It tries to connect over TCP 135 (RCP Port Mapper). I expected that it tries over HTTP/HTTPS connections. I logged this behaviour per Ethereal tool on my Outlook client computer. I have the following network configuration for Exchange Services: INTERNET <> NETSCREEN FIREWALL 1 <> ISA Server 2004 <> NETSCREEN FIREWALL 2 <> INTERNAL NETWORK with Front-End-Excahneg + Back-End-Exchange + Global Catalog. Outlook Webb Access over HTTPS works very well. I have the same Certificate and the same Common Name for RPC connections. I tested https://owa.intra.exchtest.net/rpc successfull (403.2 error). My Outlook client computer has Windows XP with SP2. I uses a proxy from client network, but NO proxy script on Internet Explorer, only proxy ports and address. I think that is a problem from Outlook 2003? Can you give me any tipp please! Thanks Mustafa ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Other Internet Software Marketing Sites: World of Windows Networking: http://www.windowsnetworking.com Leading Network Software Directory: http://www.serverfiles.com No.1 ISA Server Resource Site: http://www.isaserver.org Windows Security Resource Site: http://www.windowsecurity.com/ Network Security Library: http://www.secinf.net/ Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com ------------------------------------------------------ You are currently subscribed to this MSEXchange.org Discussion List as: raj.periyasamy@xxxxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Report abuse to listadmin@xxxxxxxxxxxxxx ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Other Internet Software Marketing Sites: World of Windows Networking: http://www.windowsnetworking.com Leading Network Software Directory: http://www.serverfiles.com No.1 ISA Server Resource Site: http://www.isaserver.org Windows Security Resource Site: http://www.windowsecurity.com/ Network Security Library: http://www.secinf.net/ Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com ------------------------------------------------------ You are currently subscribed to this MSEXchange.org Discussion List as: glara@xxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Report abuse to listadmin@xxxxxxxxxxxxxx ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Other Internet Software Marketing Sites: World of Windows Networking: http://www.windowsnetworking.com Leading Network Software Directory: http://www.serverfiles.com No.1 ISA Server Resource Site: http://www.isaserver.org Windows Security Resource Site: http://www.windowsecurity.com/ Network Security Library: http://www.secinf.net/ Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com ------------------------------------------------------ You are currently subscribed to this MSEXchange.org Discussion List as: al.mulnick@xxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Report abuse to listadmin@xxxxxxxxxxxxxx ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ ------------------------------------------------------ Other Internet Software Marketing Sites: World of Windows Networking: http://www.windowsnetworking.com Leading Network Software Directory: http://www.serverfiles.com No.1 ISA Server Resource Site: http://www.isaserver.org Windows Security Resource Site: http://www.windowsecurity.com/ Network Security Library: http://www.secinf.net/ Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com ------------------------------------------------------ You are currently subscribed to this MSEXchange.org Discussion List as: michael@xxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Report abuse to listadmin@xxxxxxxxxxxxxx