On January 30th, 2012, Microsoft announced that it had completed a major development milestone on the next version of the Office Suite. Unfortunately, the Technical Preview Beta is already full, but there will be a public beta program that will be announced this summer.

Why should you care about Office 15? Well, if you are a decision maker or are in charge of a SharePoint, Lync, Exchange, Project or Office deployment…you will want to start preparing now. If this release follows the pattern of previous versions, upgrades from 2 versions previous will be painful. This means Office 2007, SharePoint 2007, Exchange 2007, and Project 2007 or earlier deployments will mean extra work and will likely push back your ability to upgrade even more.

What’s special about this release? Office 15 will mark the first time that Microsoft will simultaneously update their cloud services, servers, and mobile and PC clients for Office, Office 365, Exchange, SharePoint, Lync, Project, and Visio. That is a HUGE release and will likely be a very big event for Microsoft.

Start preparing now! Contact your eGroup sales agent to ask how you can better prepare your environment and users for the next wave of technology!

Recently I worked with a customer that who was experiencing some odd spam false positive behavior. Even though they had purchased and deployed a third-party spam filter, Exchange was still evaluating each piece of mail and moving suspected spam emails into each user’s Junk Mail folder. This was considered undesired behavior. Any mail that made it past the third-party spam filtering appliance was to be treated as known-good.

Unfortunately you can’t simply disable the native Exchange spam filter, but you can achieve equivalent behavior. Here’s how:

Examine the email headers on a piece of false-positive spam (in Outlook 2010, File -> Properties -> Internet Headers) and note the value of the X-MS-Exchange-Organization-SCL line. In this case, the value was 9 (out of a possible 9) meaning Exchange had analyzed the email and determined (with a high degree of confidence) that it was spam.

Launch the Exchange Management Shell (it’s Powershell for Exchange). It should connect to your Exchange server automatically. Run Get-OrganizationConfig and note the value of the SCLJunkThreshold line. This value determines the maximum spam rating that is allowed to go straight to a user’s mailbox. Mail with a higher rating will go to the Junk Mail folder instead. This field accepts a maximum value of 9, so if we set it to 9 we will effectively tell Exchange to trust all incoming mail.

Run Set-OrganizationConfig -scljunkthreshold 9 (where 9 is the new value that you want the server to trust).

You can view the new value has taken effect by re-running Get-OrganizationConfig.

There’s no need to run this command on each Exchange server – just run it once on any server and it replicates to other mail servers in the organization.

I ran into this issue on an Exchange 2010 SP1 with a few users, but not all across the board.

After troubleshooting it down, I found that the common link was users that were migrated from the previous 2003 Exchange farm.

Cleaning the Outlook rules was the first logical step, but it didn’t fix the problem then I went through and checked the MAPI connections using MFCMAPI (link here).  When I checked the rules, the Out of Office wasn’t there, even though it had been set in Outlook and OWA.

To fix the issue, finally, I had to clean the Databases that the users that were migrated 2003 were located on.  It appears that there was some MAPI corruption that migrated over with the users.

To clean the database, run the following command in Exchange Powershell:

New-MailboxRepairRequest  –Database “Database name”  -CorruptionType  SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

Good Luck!

You also see ”Microsoft.Mapi.MapiExceptionMailboxQuarantined” in the Exchange Management Console when trying to local migrate a mailbox to another store

First off, do a restart of the Exchange Information Store Service.  Might save you some time. 

If that doesn’t do it, try this:

1) Open Exchange Management Shell

2) Run get-mailbox -identity <user name> |fl

3) Once you have the mailbox guid, open regedit.

4) Navigate to HKLMSYSTEMCurrentControlSetServicesMSexchangeISServernamePrivate-dbguidQuarantined Mailboxes {Mailbox guid}.

5) Remove the guid from the quarantine by deleting it.

6) Restart the Exchange Information Store Service and try again.

Quick note here -

If you are installing Exchange 2007 or Exchange 2010 and are in an environment where your local domain is different that your public domain, you might run into an issue getting your Outlook Clients to connect when they are not on the network.

There is a quick and easy fix to this, though. Open a powershell session and enter the following commands:

Get-ExchangeCertificate

This will give you the information on the certificates that are being used. Find the one that is being used for the public connections and copy the thumbprint number.

Then type the following:

Enable-ExchangeCertificate -Thumbprint XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -Services “SMTP”

(where the XX’s are the number copied from the previous command)

This enables the RPC services to use the certificate when connecting outside of the local network.