It is well known that an Outlook client sending too many RPC connections per second could result in overall Exchange server performance degradation. It could be a desktop search engine, e-mail archiving products, custom apps written to manipulate exchange mailbox data… the list goes on.

In the past, the solution to this for Exchange administrators was limited. It is not practical at times to call the user who is causing too many RPC requests and wouldn’t it be better if the issue can be handled transparently?

Exchange Team answered that in Exchange Server 2007. The feature is called Client Throttling. RPC Client Throttling computes remote operation (ROP) statistics based on overall RPC average latencies. If high ROPs per second is detected (excluding short spikes) the back-off request is sent to the client.

For Outlook 2007 clients, a ropBackoff request is added to the back-off queue. ropBackoff is a new function in Outlook 2007 and earlier Outlook client do not understand this function.

Yes grasshopper, I know, I have the answer, patience!

For Outlook 2003 clients and earlier versions, the status code RPC_S_SERVER_TOO_BUSY is sent instead.

You can tune Throttling Factor using RPC Throttling Factor registry key. I can write a lot but I will instead send you to the great article written by great minds at Exchange Team. If you read this article, I promise, you will not be disappointed.

It must be satisfying when you say back-off and they obey!

As I was browsing away, my IE crashed. Vista then asked me if I wanted to send collected data to Microsoft. I said yes.

This is when I started thinking what information is being collected from my computer and how is it used. A quick search resulted in a pleasant surprise.

The surprise was how much information is published about each feature of Vista, what information it collects, processes and transmits. How the information is used by Microsoft and what choices users have.

If you are an Enterprise administrator and ask, forget Vista, tell me how do I control communications from my Windows Server 2008 machines. What features of Windows Server 2008 communicate to Internet and how the information flows? What ports do they use? What if I want to prevent Windows Server 2008 from communicating over Internet to satisfy my organization’s security requirements?

Well, I am glad to inform Microsoft has provided detailed documentation on this as well. you can access it here.

I like it the way the documentation is clearly defining each component and how it communicates back to company servers, information collected and choices users are provided with. I have yet to find such details from other vendors.

I don’t believe anyone reading this post would not care about privacy policy. For those who don’t, I would let you read the quote below.

Quote of the day:
An ignorant person is one who doesn’t know what you have just found out. - Will Rogers

A common tool that is used for X2P & X2V migrations is called PowerConvert from Platespin. Generally speaking the servers that are being migrated are put on the same internal network segment and therefore relatively easy to migrate. However, I wanted to examine how the process works if that is not the case and one or more of the elements are segregated by a firewall.

There are three elements involved in the migration process:

1. Source Server
2. Destination Server
3. Platespin Powerconvert Server

The communication between these elements is over the following ports:

Server Discovery:

22 TCP SSH Port used when discovering Linux source servers or VMware
ESX/VMware Infrastructure 3 Servers

443 TCP SSL Port used to connect to the VI3 web services when discovering ESX servers.

135/445 TCP For DCOM/RPC communication as PowerConvert utilizes WMI when discovering Windows based servers so that no manual configuration is required

**WMI (RPC/DCOM) may use TCP ports 135 and 445 as well as random/dynamically assigned ports above 1024.

Server Conversion:

80 TCP - For HTTP communication between the PowerConvert Server and the source/target machines.

443 TCP - For HTTPS communication (if using SSL) between the PowerConvert Server and the source/target machines. This is also the default port for the VMware Infrastructure 3 Web service.

3725 TCP - File Transfer port used between the source and target machine.

SMB (TCP 139, TCP 445, UDP 137,UDP 138) - File Transfer of the Take Control folder (i386) and files from the PowerConvert server to the source server.

135/445 TCP - For DCOM/RPC communication as PowerConvert utilizes WMI when taking control and rebooting the source server.

**WMI (RPC/DCOM) may use TCP ports 135 and 445 as well as random/dynamically assigned ports above 1024.

 

These ports must be opened on the firewall to allow the conversion to complete. An alternate method would be to temporarily place a PowerConvert Server in the DMZ.

 

References:

http://support.platespin.com/kb2/article.aspx?id=20341

http://support.platespin.com/kb2/attachments/Ports_diagram.pps

I am currently preparing to take the VMware Certified Professional certification exam. While exploring online, I came across this great reference card. It can be a great reference for anyone administering VMware or preparing for the exam. Check it out!

http://www.vmreference.com/vi3-card/

I have spent a lot of time recently investigating storage solutions as part of a migration design for Exchange 2007.

The current implemented solution is a multi-node Exchange 2003 cluster with SAN based storage (No HA/DR). With Exchange 2007 the desire is to deploy a  CCR/SCR solution to allow for data redundancy, disaster recovery, and site resiliency. The toughest decision that I have been faced with (given that I am not a storage guru) is in storage design. Should it be a DAS or SAN based solution? Each has benefits and negatives. Here are my random thoughts on the subject.

Performance:

Traditionally storage has always been the bottleneck in systems hosting heavy IO applications like Exchange. With the transition to 64-bit in Exchange 2007, IO has been significantly reduced. This has allowed DAS (mainly Serial-Attached SCSI) to become a viable alternative solution for Exchange deployments.

Scalability:

SANs are very scalable but as they scale the TCO increases. DAS based solutions are able to scale less but at a much lower cost.

Availability:

Any shared storage represents a single point of failure. Although it is rare for a SAN to fail, anything is possible. The HA and DR solutions offered by SAN vendors are generally very expensive and difficult to implement and support. The CCR/SCR solutions offered by Exchange 2007 in combination with DAS storage, offer a lower cost and easier to manage, high availability solution.

Cost:

DAS based solutions can offer a significant cost savings over SAN based storage.

Some additional points to consider:

Footprint – DAS based storage array cabinets from most vendors (HP, Dell) that I have investigated, require 2U of rack space each. Any significant storage requirements would lead to significant rack space, power, and cooling requirements.

Administration – DAS allows for more centralized control of the storage configuration by the messaging team. The setup and maintenance is less complex than prior SAN configurations and does not include the need  to rely on a storage administrator for assistance.

This is an interesting and important area to investigate as part of any Exchange deployment. As with any solution, a lot depends on what you current requirement is and future requirements are.

References:

http://technet.microsoft.com/en-us/library/cc500980.aspx

http://www.emc.com/collateral/demos/microsites/mediaplayer-video/henderson-exchange.htm

http://msexchangeteam.com/archive/2006/10/05/429103.aspx

I noticed that Outlook 2007 feeds were not updating for weeks and I had ignored the issue but now that I was missing on important feeds I started looking for solution.

First thing I did was to remove all feeds from Outlook, but I could have tried to fix it instead. I found this article on Realtime Windows Server blog.

Now that I was ahead, I had to find something else. Now how do I import IE feeds back in Outlook? It started getting frustrating to find where IE stores it’s feeds. It’s not in favorites. This is when I stumbled upon Joel’s post at exchangeexchange.com. This allowed me to take IE feeds and import them back in Outlook.

Not sure what caused Outlook to stop updating feeds. That is for next time. It is working for now so I’ve got few feeds to read. Later.

Quote of the day:
The nice thing about egotists is that they don’t talk about other people. - Lucille S. Harper

I always liked looks of the old scripture pages but I never imagined I will have my website look like one. I never had the skills to design a web page.

Today, however, I have the site with the design I like and functionality that gets the job done. All of this thanks to advancements of technology and willingness to share by the creators and community who supports WordPress.

Read the rest of this entry »