Fix: Workstation optimization "Amateur Hour"

Several of the new clients we’ve taken on from other IT companies (who shall remain nameless) have users who have “gotten used to” the following MSConfig dialog box popping up during boot:

Every time I see this, I cry a little—and I believe my life gets a few minutes shorter as a result.

There is no appreciable reason to use MSConfig to limit startup items on anything but a troubleshooting basis.

If you’re trying to optimize which items run at startup, I’d highly recommend a utility like Sysinternals Autoruns, downloadable from here: http://live.sysinternals.com/autoruns.exe

You still have to know what you’re doing when you’re using Autoruns to remove superfluous startup entries—namely to know the difference between what is a legitimate startup entry and what isn’t strictly necessary, so please be careful with this utility.  But hey, you’re already feeling confident enough to selectively disable certain Startup Items, so why not take the next step and remove them properly?

There’s an excellent, in-depth article here about which types of programs can be safely removed here:

http://www.pacs-portal.co.uk/startup_content.php

Again, use extreme caution… use Autoruns to disable before you delete startup entries.  But please, for the love of the Flying Spaghetti Monster, stop using MSConfig!

Fix: The culprit behind 80% of Exchange crashes

If you’ve worked with me long enough, you’ll know that one of the first questions out of my mouth when you ask me for help with random Exchange crashes is, “Is the Symantec Information Foundation Mail Security for Microsoft Exchange fully up-to-date?”

I wish I didn’t have to ask this question—SMSMSE is an ancillary product in many cases—it supplements the AV scanning engine of whatever the client’s Anti-Spam solution is.  Very few clients use the SMSMSE’s anti-spam capability, in favor of a third-party appliance (usually a SonicWALL E-Mail Security) or a hosted service (such as Postini); however, by virtue of having been licensed for Symantec’s full protection suite, we frequently like to install SMSMSE as a “second safety-net,” given that the Anti-Spam solutions typically use a virus scanning engine other than Symantec’s.

Unfortunately, when troubleshooting an Exchange issue, which may include:

Ø  Crashing the Microsoft Exchange Transport service

Ø  ASP.NET errors

Ø  Stopping mail flow without errors in the Event Log

Ø  Blue screen (STOP) errors

…the last place that folks think to check is the SMSMSE, yet (in my experience), 80% of these issues are caused by an out-of-date SMSMSE conflicting with a recent security update or patch.

At two clients recently (also including us), we were running version 6.5.2.82, which caused ASP.net error shown below.  In one case, this same error was the precursor to a halt to mail flow:

Log: Application

Type: Warning

Event: 2262

Agent Time: [REDACTED]

Event Time: [REDACTED]

Source: W3SVC-WP

Category: None

Username: N/A

Computer: [REDACTED]

Description: ISAPI 'C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

After having set up a custom monitor set to catch this error, all three servers that were experiencing this all had one thing in common… version 6.5.2.82 of SMSMSE:

…hence my recommendation in the bubble above.  If the “Currently available version” of SMSMSE is greater than the “Installed version,” I’d highly recommend installing the update ASAP.

The upgrade from 6.0.X to 6.5.X, and from 6.5.2.X to 6.5.2.Y is quite simple, takes about 15 minutes (after you download the ~400MB installation file from FileConnect), and only restarts the Microsoft Exchange Transport service.

During the installation (upgrade), you’ll notice that it registers some new types with ASP.NET 2.0.50727.1433 (also the same ASP.NET version loaded on all three problematic servers), thus also confirming my suspicions that the issue relates to an incompatibility between ASP.NET 2.0.50727.1433 and SMSMSE 6.5.2.82:

At the time of this writing, the most recent available version is 6.5.2.97… when scrolling through the list on FileConnect, make sure you’re getting the latest iteration of 6.5, as the list sorting is a bit wacky.  Just look for the correct file with the most recent date:

Again, you’ll be surprised how many Exchange-related issues this upgrade will fix—and why that’s usually the first question I ask.

Fix: Outlook for Mac 2011 & Exchange 2007: Unable to send messages over ~5MB

After having scoured the Internet long and hard and trying a variety of solutions, I’m prepared to label this a “Fix” with the caveat that I’m not entirely sure which setting actually “did the trick.”  There are an abundance of forum posts out there about this very issue—I’d even gone so far as to place a (free) call into the Microsoft Outlook for Mac 2011 product support team, who in turn tried to convince me that the issue was with Exchange and not Outlook (which is not true, as this issue does not occur in Entourage 2008… a point I was unsuccessful at arguing).

Yes, I’m aware that Outlook for Mac 2011 (hereafter referred to as Outlook 2011, as there is no Outlook 2011 for PCs) communicates using the Exchange Web Services (EWS) instead of WebDav; however, Outlook 2010 (for the PC) also uses EWS without issue.

Anyway, onto the problem… when running Outlook 2011 and attempting to send a message over ~5MB in total, you’ll end up with the following error (check for the little yellow exclamation point on the bottom right of your screen):

…and when you click on the little yellow exclamation point, you get:

  

Outlook 2011 then drops the message that failed to send into your “Drafts” folder.

I narrowed it down to a total message size of ~5MB that failed in this way.  Note that I said message size, because even though your attachment size might be exact, the MIME conversion adds overhead to the messages (around 20-30% from what I’ve seen).

By way of example, this was the sending progress indicator for a message with an 8MB attachment (notice how it’s 9678 KB):

 

First, I updated the web.config files in the following directories on the Exchange 2007 server:

C:\Program Files\Microsoft\Exchange Server\ClientAccess\Sync
C:\Program Files\Microsoft\Exchange Server\ClientAccess\Exchweb\EWS

…in said web.config files, I modified the maxRequestLength attribute, changing it from the default of 10240 to 30720.

I then restarted IIS using the Internet Information Services (IIS) Manager snap-in, highlighting the server, and clicking Restart:

 

(Note that you may have to hit “Restart” a few times… the IIS Manager is a bit buggy and doesn’t wait long enough for IIS to stop before it complains.)

Unfortunately, I now had a new problem… when sending, I’d now get this error instead:

 

So I then updated the Send Connector (which in this case was going to a Smart Host (irrelevant… you can just update the default one)) to allow messages up to 30720 KB:

 

Still, no love from Exchange.  I found one other command on another newsgroup that I tried as a last-ditch effort.  I have duplicated & modified that command here.

First, I ran the command that gathered information about the value I was going to be setting, and popped up Notepad, which I could then use to search for the requestFiltering section and verify that the maxAllowedContentLength attribute (set in the next command) was not yet present:

%WINDIR%\System32\appcmd list config "Default Web Site/owa" > currentConfig.txt & notepad currentConfig.txt

Once I confirmed that maxAllowedContentLength was not present in the requestFiltering section, I ran the following command to add it and re-check the current configuration:

%WINDIR%\System32\Inetsrv\appcmd.exe set config "Default Web Site/owa" -section:requestFiltering -requestLimits.maxAllowedContentLength:31457280 & %WINDIR%\System32\Inetsrv\appcmd.exe list config "Default Web Site/owa" > currentConfig.txt & notepad currentConfig.txt

If you’re wondering where I came up with 31457280, that’s 30 MB in bytes, that’s right, bytes.  If you set this value thinking it’s in KB, you’re going to break your ability to send anything but the smallest messages.

Here we can see the value set up:


At this point, I restarted IIS again (per my aforementioned procedure) and attempted to send my slew of test messages… they all went through, as we can see in the Sent Items in Outlook 2011:

 

…and in the Inbox of my OWA account:

 

Needless to say, the client was very pleased to now be able to send e-mails over 5MB in size.

If you’re wondering why I didn’t test beyond 10 MB, it’s because many recipient e-mail systems won’t process messages that large—and as such, I don’t recommend to clients that they send anything over 10 MB as a “general rule.”

Fix: The one Exchange/AD checkbox that will get you EVERY TIME...

There are all sorts of Exchange, BlackBerry and Outlook-related issues that can be caused by this one magical checkbox not being checked.

I won’t go into all of them… they’re all obscure, they’re all frustrating, and nobody ever thinks to check this checkbox, because there is no good reason why it should ever be un-checked.

So, if you’re slamming your head against a wall trying to figure out:

·         Why won’t the damn BlackBerry send?

·         Why can’t Suzie log in to OWA?

·         Why can’t I delegate mailbox permissions properly?

·         [Insert other obscure Exchange-related issue here]

Open up AD Users & Computers.

Go to View > Advanced Features (make sure it’s checked/enabled).

Find the user’s account, go to the Security tab, and click Advanced.

Check this checkbox… it should always be checked.  If it’s not, check the box and wait a few minutes and try whatever you were trying to do again:

You’d be surprised how many Exchange issues this will fix…

Fix: Unable to Disable Automatic Java Updates on Windows 7 and Server 2008

There's a UAC issue that prevents you from disabling the automatic update check for Java when loaded on Server 2008 and Windows 7.

To fix the fact that the checkbox doesn't work:

…change this registry value to 0:

HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\EnableJavaUpdate

…or on an x64 machine, that's:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy\EnableJavaUpdate

The setting should take effect immediately.  You can now right-click the Java Update icon and choose Cancel.