In a previous article we pointed at how MS stated to control the port delegation as the link will outline the process.

In IIS6 you can also do this :
http://support.microsoft.com/?id=555022

However it has come to our attention there is another twist which has been observed on a number of machines. Having done this I know first hand on one day I have a machine which can do Passv mode without issue. Then out of the blue the machine suddenly cannot do passive mode and clients who depend on it were left out in the dark, and the complaints come in. I was dealing with a complaint like this where I was sure the lady was going to kill me. Though I must say she is a good person and worked with us till I found the cause of the problem. In most cases it will not end this friendly.

While the edit is working correctly the Windows Firewall/Internet Connection Sharing (ICS) service seems to be the cause the failure. It is supposed to work where after the client issues a passv command, the server responds with one of its transient ports used as the server-side port of the data connection. After a data connection command is issued by the client, the server connects to the client using the port immediately above the client-side port of the control connection.

However the service Windows Firewall/Internet Connection Sharing (ICS) is also involved in the process and has been verified as the part which is blocking the return and thus the passv command will be ignored or denied. I have personally observed that simply restarting the service will resolve the problem. A warning if you are connected via remote desktop, when restarting the service your desktop session might be lost. Though I have personally only noticed a freeze up for a bit and returns to normal.