Getting E-Mail Auto forwarded by a Rule

Do you have a user getting email "forwarded" from a long gone employee? Do you keep old employee's mailboxes around in order to keep getting their emails or for archiving? Interestingly at least in Exchange 2003 rules will continue to fire even for disabled user accounts. If you get emails with "Auto forwarded by a Rule" in the body this is likely what you are experiencing (Unfortunately this notice was removed from later versions of Exchange). The only way to remove this rule is to recreate or enable the user, connect a copy of Outlook, login and disable the rules. Ok to be honest that is not the "only way" you can also use mcfmapi but this is more complicated and runs the risk of causing other problems.

SBS Server only 5 CALS

I have run into this several times lately and felt this issue was important enough to repost how to fix the problem. Full credit goes to the "Knight-Time Ramblings blog" who originally posted this fix.

In a nutshell Small Business Server 2003 stores its license data in the windows\system32 folder on the server and if this drive fills up it tends to corrupt the license file. There are also reports that certain AV programs may corrupt it. The best solution is of course to have a backup of these but if you don't you can fix this by doing the following


  1. Open services.msc
  2. Stop the License Logging Service
  3. Rename %windir%\system32\licstr.cpa to something else like licstr.cpa-old
  4. Copy %windir%\system32\autolicstr.cpa to licstr.cpa
  5. Start the License Logging Service
Server management should now show the correct number of licenses.

Sender Email address with Apostrophe gives 550 Requested action not taken: mailbox unavailable

This was another fun one because there were no logs on the Exchange server to show it ever saw the message and my spam filtering service was passing the email and saying my Exchange 2010 server was responding with:

550 Requested action not taken: mailbox unavailable (in reply to MAIL FROM command)

The senders email address was like this first.o'last@domain.com which is technically a valid address but I frequently see admins remove the apostrophe to avoid complications.

I finally figured out that yes this error was happening where I suspected on our WatchGuard firewall. For some reason their SMTP proxy disallows this character by default even though it is valid. To fix:
  • Open WatchGuard System Manager then Policy Manager. Right click the SMTP-proxy rule then select Modify Policy option.
  • lick the View/Edit Proxy button in the right side of Proxy action field.
  • (Fix Sender) Mail From of the SMTP-proxy, click Change View button to switch to Advanced View. Click Edit button to edit the Non-allowed characters rule.
  • Add the apostrophe at the end of default Regular Expression then click OK.
    Change from [^-_.+=%*/~!&@?0-9a-zA-Z] to [^-_.+=%*/~!&@?0-9a-zA-Z']
  • (Fix recipient) Rcpt To of the SMTP-proxy, click Change View button to switch to Advanced View. Click Edit button to edit the Non-allowed characters rule.
  • Add the apostrophe at the end of default Regular Expression then click OK.
    Change from 
    [^-_.+=%*/~!&@?0-9a-zA-Z] to [^-_.+=%*/~!&@?0-9a-zA-Z']
  • To enable save the config to the device.

Searching returns no results even though you can see files in folder

This one was fairly obscure to find and the cause of the problem probably exists on desktops as well as servers.  I recently had a customer who could search in all of their drives and folders on their server except their main share. From within this folder I would search for *.doc or *.docx files I could see right there in the folder and it would immediately return no results found like it was not even trying to search.

The cause? Someone had removed the SYSTEM account from this branch of folders. The SYSTEM account must have full permissions to files and folders in order to index them.

Once I added the SYSTEM account back on indexing took off and indexed about 60,000 more items and I was able to search for files and get results.