There are work-arounds in Microsoft Exchange when you need to do things such as disable SSL 2.0 or resolve sync issues.
With guest contributor Georg Hinterhofer
Q. We recently performed a security audit of our IT infrastructure. One of the recommendations was to disable SSL 2.0 for Web services, including Exchange services such as Web Access, Outlook Anywhere, Exchange Web Services and so on. What’s the best way to do this?
A. First, let’s look at why your security consultants are recommending this change. SSL 2.0 was developed back in the mid-1990s (as was SSL 3.0, by the way). It was one of the first commonly used encryption and authentication protocols on the Web. However, SSL 2.0 has a couple of weaknesses that could lead to man-in-the-middle and other types of attacks. Furthermore, SSL 3.0 features a good deal of functional improvement.
How does this affect Exchange? Well, Exchange doesn’t have its own encryption protocol. Instead, it relies on the encryption services provided by the base OS. So Exchange will use whatever protocol or cipher you allow or disallow in the OS encryption services.
The basic process is outlined in the support document, “How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services,” and applies to all current versions of Windows. If you want to disable SSL 2.0, take the following steps:
Figure 1 This value type is part of the process of disabling SSL 2.0.
This same procedure works for any other protocol you need to disable, such as Private Communications Transport (PCT) 1.0. It even works on a Microsoft Forefront Threat Management Gateway box, in case you’re using one or more of these for publishing Exchange.
You might also be asked to disable weak ciphers, such as DES 56/56 and so on. You can diable these in the same manner. Simply add a DWORD called “Enabled” into the respective registry hive and set its value to 00000000. Make sure you always do the proper amount of testing with all required clients to ensure you don’t break any client functionality by disabling a server protocol or cipher.
Q. Ever since we moved to Exchange 2010, we’re having numerous sync issues with our Outlook clients in cached mode. The error messages state that something went wrong with synchronizing the Organizational Forms library. This leads to help desk calls, which in turn leads to user dissatisfaction. My clients can no longer use forms when they’re not connected to Exchange. Is there anything we can do about that?
A. The exact error message you’re seeing probably looks something like this:
19:23:23 Synchronizing Forms
19:23:23 Downloading from server FQDN
19:23:23 Error synchronizing folder
19:23:23 The client operation failed
This might be filling up your sync issues folder. It’s only going to show up once you have an Org Forms folder hosted on an Exchange 2010 Public Folder Store. The reason for this is a coding bug in Exchange 2010.
Until now, you really only had two work-arounds. You could remove the Org Forms folder from the hierarchy (this was only possible if you didn’t have to host any forms in there). You could also have the client go somewhere other than an Exchange 2010 Public Folder store for forms by hosting them on an Exchange 2007 Public Folder store, if possible.
Luckily, after a couple of attempts to get a bug accepted, Exchange Sustained Engineering fixed the underlying issue. The fix is described in the support document, “‘80004005-501-4B9-560’ synchronization error logs in the Outlook Sync Issues folder.” It’s also available as part of the Exchange 2010 SP2 Update Rollup. After that, clients should stop seeing these errors, and should also be able to use forms offline again. You should note that this won’t fix any other sync issues you might have, such as those involving Offline Address Book and others.
Q. We‘ve recently had a couple of outages related to extensive resource consumption on our Client Access Servers. We found that an instance of w3wp.exe is consuming most of the available resources. Can you shed some light on why this might be happening?
A. Chances are that you have one or more Active Sync devices on the lam. Lately, we’re seeing more instances of this happening. Luckily, identifying those devices is relatively straightforward, thanks to our friend Log Parser.
Basically, all the information you need to figure this one out is stored in the IIS logs written out of the box. By default, if your system disk is C:\, those logs are stored in C:\inetpub\logs\LogFiles\W3SVC1. When opening up any of those log files, you should see all hits for Outlook Web Access, ActiveSync, Exchange Web Services and so on.
Download a copy of Log Parser 2.2 and install it on either Exchange itself or on any management server. If you’re using a management server, make sure that Windows PowerShell 2.0 is installed as well. Also download a copy of the ActiveSyncReport script and bring it on to the server.
Let’s say you want the top 10 devices based on hits. All you’d need to do is run:
\ActiveSyncReport.ps1 -iislog "C:\inetpub\logs\logfiles\w3svc1\" -logparserexec "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -activesyncoutputfolder c:\EAS -htmlreport -tophits 10
As you can see in Figure 2, the top talker is a device with more than a million hits. That’s clearly way too many hits, and definitely warrants further investigation.
Figure 2 You can determine which device has the most hits.
How about the top 10 devices from a specific date? That’s easy. Just run this:
\ActiveSyncReport.ps1 -iislog "C:\inetpub\logs\logfiles\w3svc1\" -logparserexec "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -activesyncoutputfolder c:\EAS -htmlreport -tophits 10 –date 7-20-2012
You’ll get a nice HTML output of the queried records in the ActiveSyncOutputFolder. There are some other usage scenarios for this script outlined in The Exchange Team Blog post, “A script to troubleshoot issues with Exchange ActiveSync.”