I ran into this issue again today so I thought I would share. I had a client who was experiencing very slow performance from his Remote Desktop Client to several servers he was accessing via TS Gateway. The problem turned out to be related to a feature found in Remote Desktop Connection 6.0 and higher. RDC 6.0 leverages the Receive Window Auto-Tuning feature found in Windows Vista and Windows 7. The problem is that the Receive Window advertised is much larger than it was in Windows XP which allows more data to be sent in larger, faster bursts. This is fine in a LAN environment but, when coming in via a WAN connection and then encapsulating the RDP traffic into an SSL stream, the net result was a lot of packet fragmentation. The following command will set the Receive Window to a more conservative value and consequently improve overall Remote Desktop performance.
netsh interface tcp set global autotuninglevel=highlyrestricted
Here’s the link to the original article that explains the problem in greater detail. Thanks guys!
Remote Desktop Slow Problem Solved
Exchange lists each hop in a message’s transmission in the email header. This is very helpful for troubleshooting mail flow problems however it also exposes internal server names to the outside world. If you would like to keep this information from being exposed externally you can implement a feature called Header Firewall on your Internet Send Connector using the following Exchange Management Shell command:
Remove-ADPermission -id "Connector Name" -User "NT Authority\Anonymous Logon" -ExtendedRights Ms-Exch-Send-Headers-Routing
Note that this command should be entered as a single command line string.
Windows Server 2008 introduced a really great new feature called Fine-Grained Password Policies. This feature allows you to create a password policy separate from the Domain level one and apply it to an Active Directory group. This is really handy for doing things like creating a stricter password policy for Domain Administrators. The problem is you have to go in via ADSI Edit to set it up making it not for the faint of heart. Parhelia Tools makes a really nice GUI front-end for Fine-Grained Password Policies called Password Policy Manager (PPM). Best of all PPM is available free. You can download it from:
How Exchange Works has a really good post on how to determine whitespace in the Exchange 2010 database. Simply run the following command in the Exchange Management Shell:
Get-MailboxDatabase –Status | fl Name, AvailableNewMailboxSpace
Windows Server 2008 introduced a new service called Terminal Services Gateway. It was renamed Remote Desktop Gateway in Windows Server 2008 R2. Its main purpose is to tunnel RDP traffic from a Remote Desktop Client to a Terminal Server farm. However you can also use it as an endpoint for any Windows workstation or server with Remote Desktop enabled via a single public IP address.
All you have to do is add all computers that you wish to remotely access to the TS RAP (resource allocation policy) in the TS Gateway configuration. Install an SSL certificate and publish the TS Gateway server out to the Internet allowing port 443 into it.
Then on the Remote Desktop Client click on Advanced tab and then the Settings button under “Connect from anywhere”. Finally enter the server name that you published out for the TS Gateway server. You can now go back to the General tab and enter any computer name that you added to the TS RAP policy and connect.
That’s it. No VPN’s, only a single publishing rule on your firewall and everything is encrypted via SSL.
In addition to the standard prerequisites required for Exchange 2010 there are several additional hotfixes required to support Exchange 2010 SP1 on Windows Server 2008 R2.
Hub Transport Role
Client Access Role
You can get the entire list of Exchange 2010 SP1 prerequisites here:
Update – Windows 2008 R2 Service Pack 1 includes the hotfixes listed above so the only additional prerequisite that will be required is the Office 2010 Filter Pack.
A question that comes up frequently in Exchange 2007/2010 implementations is do I really need a UC Certificate? A Unified Communications certificate, aka a SAN (Subject Alternative Name) certificate allows additional FQDNs to be attached to an SSL certificate in addition to the common name. The only time a UC certificate is absolutely required is if you are planning on utilizing Outlook Anywhere. Outlook Anywhere attempts to find the Exchange Autodiscover service by trying to connect to https://autodiscover.domainname.com/autodiscover/autodiscover.xml.  Typically nobody wants to use autodiscover.domainname.com as there OWA address so this is where the UC Certificate comes into play. If Outlook is inside your network it looks to the SCP value in Active Directory to determine the location of Autodiscover which can then be set to https://owa.domainname.com/autodiscover/autodiscover.xml using the Set-ClientAccessServer cmdlet. So, if you aren’t using Outlook Anywhere you can get by with a standard single-name SSL certificate and save a little money. If you do need a UC certificate I would recommend either Comodo (www.instantssl.com) or GoDaddy (www.godaddy.com). Both are relatively cheap and are supported by most devices.