Messaging Records Management [MRM] for free spirit environments

-formerly called Mailbox Manager in Exchange 2003

This feature is often discussed when setting up compliance policies, however, MRM can also be used in a low impact way to help reduce high item count for frequently used mailbox folders.  High item count impacts Exchange server performance regardless of whether Entourage or Outlook is used to access information.  The details of this impact are expanded here:

http://technet.microsoft.com/en-us/library/cc535025(EXCHG.80).aspx

Neil Hobson at MSExchange.org has a good 2 part article on how MRM is setup.  This quick run through is a good first exposure to the user interface and syntax of MRM if you haven’t looked into it before.

http://www.msexchange.org/articles_tutorials/exchange-server-2007/compliance-policies-archiving/exchange-2007-messaging-records-management-part1.html

http://www.msexchange.org/articles_tutorials/exchange-server-2007/compliance-policies-archiving/exchange-2007-messaging-records-management-part2.html

The general idea in a free spirit environment is to implement an intuitive workflow with few if any restrictions.  Common solution requirements are:

·         old messages still searchable

·         message retention online, not a local file

·         forever email - message retention with no limits to age

·         no impact to information consumption and retrieval by VIPs

·         minimal impact to performance - increasing server resources before enforcing user quotas

With MRM, these solution requirements can be met.  Here is an outline of an implementation:

1)      discuss workflow options with VIPs - performance vs. information consumption and retrieval

2)      create new managed custom folder

3)      create new managed content settings

4)      create and apply policy to users

5)      schedule MRM folder assistant

Here are some details for each of those steps:

1)      discuss workflow options with VIPs

The main ideas to convey during this discussion is how item count in critical path folders [Calendar, Contacts, Inbox, and Sent Items folders] impacts performance as much or more than having a large total mailbox size.  Generally with Exchange 2007, this performance impact will happen at 20,000 items.

·         What critical path folders currently exceed this?

·         Would creating a new folder or folders to automatically move older items into disrupt your information consumption and retrieval? [these items will still be searchable as before]

·         Determine an age at which to move items.  For instance, Inbox items older than 3 years, and Sent Items older than 1 year [Contacts and Calendar items need special care, but much less likely these carry more than 20,000 items].

·         Ask opinion about best way to tailor workflow for them

2)      create a new Managed Custom Folder

Depending on the dialog with VIP user / groups, create one or more managed custom folders.  Here’s an example of what that might look like:

·         create a custom managed folder called Archives

3)      create New Managed Content Settings

Again, depending on the dialog with VIP user / groups, create one or more managed content settings to automatically move items to appropriate folders based on age

·         create a managed content setting for the Inbox Managed Default Folder moving Message Type: Emails older than 1000 days to the Managed Custom Folder: Archives

·         create a managed content setting for the Sent Items managed default folder moving Message Type: Emails older than 365 days to the Managed Custom Folder: Archives

4)      create new Managed Folder Mailbox Policy

·         add the managed folders and managed custom folders from above [Inbox, Sent Items, Archives] and name the policy something appropriate for the user or users it will be applied to - for example, VIP archive workflow

·         using the Exchange Management Console, apply the policy to a user from their mailbox settings tab

5)      schedule the MRM folder assistant

·         customize a schedule to run at a set time each day or even once a week.

·         you can manually get things going with the Exchange Command Shell command

Start-ManagedFolderAssistant -id MBXserver

Here’s an example of what this will look like in Entourage and Outlook 2007 after implementing the example plan above:

[for this example, I made the retention just 1 month as I didn’t have items 3 years or 1 year old for the respective folders].

Proxy servers or settings can interfere with HTTP(S) traffic.  Firefox has the option to use it's own settings, so even if a URL works there, Safari and other port 80, 443 requests will use proxy settings in Network Settings.  Check there first!

Many times using a Hosts file will help ensure the issue isn't a name resolution problem.  To make manual entries in a Hosts that will override DNS settings ==> Open Terminal in Utilities folder, then paste the following line - need to be administrator and provide password when prompted

sudo "/Applications/TextEdit.app/Contents/MacOS/TextEdit" /etc/hosts

 Next, use the Microsoft Exchange Remote Connectivity Analyzer to test from outside your network.

http://testexchangeconnectivity.com/

Lastly, if you need to verify URLs inside your network and don't have Outlook 2007's Test E-mail Autoconfigure available, then you can use a utility called curl that comes with Mac OSX.

 1) create new shell script called autodiscover.sh copying the code below to automate the curl utility
 2) sample usage:

./autodiscover.sh -e https://autodiscover.contoso.com/autodiscover/autodiscover.xml -a JohnDoe@contoso.com -u contoso\\JDoe

*note - after creating the .sh file on your Mac, you may need to give file, autodiscover.sh the proper permissions.  
For example, run ​chmod 766 autodiscover.sh

**note - the double backslash \\ isn't a typo!  Curl requires an escape character for the domain specifier in the -u option for username​.

#############################################

#! /bin/bash
function print_usage()
{
 echo "Usage: `basename $0` [options]"
 echo "Options:"
 echo "  -e  Autodiscover Endpoint URL"
 echo "  -a  SMTP address of account to perform autodiscover"
 echo "  -u  user ID used when logging into the specified Autodiscover Endpoint"
 exit 2
}
function parse_args()
{
 args=`getopt u:e:a: $*`
 if [ $? != 0 ]; then
  print_usage
 fi
 
 set -- $args
 for i
 do
  case "$1" in
   -e)
    autod_url="$2"; shift
    shift
    ;;
   -a)
    autod_email="$2"; shift
    shift
    ;;
   -u)
    autod_id="$2"; shift
    shift
    ;;
   --)
    shift
    break
    ;;
  esac
 done
 if [ -z "$autod_url" ] || [ -z "$autod_email" ]; then
  print_usage
 fi
}
function generate_autod_request_xml()
{
 _email_address=$1
 autod_xml=""
 autod_xml+='<?xml version="1.0" encoding="UTF-8"?>'
 autod_xml+='<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006%22%3E'
 autod_xml+='   <Request>'
 autod_xml+='      <EMailAddress>'$_email_address'</EMailAddress>'
 autod_xml+='      <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>'
 autod_xml+='   </Request>'
 autod_xml+='</Autodiscover>'
}
parse_args $*
generate_autod_request_xml $autod_email
xml="$autod_xml"
/usr/bin/curl --silent -k --header 'Content-Type: text/xml' --user "$autod_id" "$autod_url" --data "$xml"

##########################################################################

 2 items that will help WM emulators on Hyper V clients in Win2k8 R2…

1.       upgrade the HyperV integration services

2.       enable MAC address spoofing on the VM in network adapter settings

Here’s the details:

I just upgraded my VMs from Win2k8 to Win2k8 R2 RTM.  I have my lab environments running in private networks to not interfere with our primary network.  I haven’t confirmed if this same symptom affects VMs on the External virtual network connection type.  My emulators were working fine before the upgrade, but after I was unable to get DNS proxies to GCs in the internal network. 

The first part I needed to do was in the upgrade documentation.  You need to rerun the Integration Services Setup from the virtual machine connection.  There are helpful event ids 27 and 6 on the Sys log of the parent partition that help clue in this resolution.

Log Name:      System

Source:        VMSMP

Date:          8/10/2009 8:40:29 PM

Event ID:      27

Task Category: None

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      mcCSIlab

Description:

Networking driver on '01XP' loaded but has a different version from the server.  Server version 3.2  Client version 0.2 (Virtual machine ID 8AF758FA-CA92-4583-BAE0-45360776EEDA). The device will work, but this is an unsupported configuration. This means that technical support will not be provided until this problem is resolved. To fix this problem, upgrade the integration services. To upgrade, connect to the virtual machine and select Insert Integration Services Setup Disk from the Action menu.

The second portion to fix was a bit more difficult to find.  I saw ARP requests in Netmon that were never answered.  This clued me in that the problem was with MAC addresses.

I’ve confirmed the resolution was to enable this setting –

So, it appears native security for the Win2k8 R2 Hyper-V clients is heightened to prevent MAC spoofing by default – MAC spoofing is exactly what the WM emulator does with the VPC network drivers to use the Hosts network card [which in this case is a client partition in Hyper-V].

I hope this helps!

First some mad props to Exchange Genie for getting the info on this out 2 years ago...

http://www.exchange-genie.com/2007/07/401-error-when-attempting-test-outlookwebservices/

I saw this issue popup recently with a Windows 2008 server with the CAS role installed.  Advanced security on Windows 2008 helps prevent NTLM man in the middle and “reflection attacks” by blocking access when the FQDN or custom hostname of the resource you’re trying to access is different from the computer name.
http://support.microsoft.com/?id=896861
http://support.microsoft.com/default.aspx?scid=kb;EN-US;926642

I recommend working around this by running the commandlet from an Exchange Command Shell that doesn’t have the CAS role.  In an All In One topology, install the Exchange Command Shell on a workstation.  The other option is to follow the steps in those support articles but weigh carefully the risk in making the server vulnerable to the attacks mentioned.

I came across some strange output when running the Exchange 2007 commandlet

 Test-ActiveSyncConnectivity

so I thought I'd share with those of you who might be trying to figure out what it means...

Test-ActiveSyncConnectivity -ClientAccessServer 02e2k7cas -TrustAnySSLCertificate:$true -LightMode:$true

CasServer  MailboxServer Scenario        Result  Latency(MS) Error           

---------  ------------- --------        ------  ----------- -----                  

02e2k7cas  mclab02E2k7MB FolderSync      Failure             [System.Net.WebException]:

The remote server returned an error: (403) Forbidden.               

HTTP response headers: MS-Server-ActiveSync: 8.1

Content-Length: 0

Cache-Control: private 

Date: Wed, 13 May 2009 20:35:31 GMT

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

In the IIS logs I saw this:

2009-05-13 20:35:31 02E2K7CAS 192.168.0.31 OPTIONS /Microsoft-Server-ActiveSync/default.eas &Log=V120_LdapC1_LdapL0_RpcC0_RpcL0_ 443 mcLab02.internal\CAS_16d82a7964354994 192.168.0.31 TestActiveSyncConnectivity - 02e2k7cas.mclab02.internal 200 0 0 15

2009-05-13 20:35:31 02E2K7CAS 192.168.0.31 POST /Microsoft-Server-ActiveSync/default.eas Cmd=FolderSync&User=CAS_16d82a7964354994&DeviceId=996795128&DeviceType=TestActiveSyncConnectivity&Log=V120_LdapC0_LdapL0_RpcC10_RpcL0_Ers1_Error:
LegacyDeviceOnStrictPolicy_ 443 mcLab02.internal\CAS_16d82a7964354994 192.168.0.31 TestActiveSyncConnectivity - 02e2k7cas.mclab02.internal 403 0 0 31

The LegacyDeviceOnStrictPolicy helped me remember I had disabled ActiveSync for nonprovisionable devices here:

So, the error, although cryptic at first, was really there to tell me the account I tested has a mailbox policy that doesn't allow nonprovisionable devices.  If you use System Center Operations Manager, you may also run into this error.

*UPDATED 6/28/2010*

The typical installation of Exchange 2007 includes the CAS, MBX and HUB roles.  Entourage requires little if any server configuration to connect in this topology.

However, once these roles are separated, there’s a few additional steps to take.

One thing to note – you do not need to install the latest WebDAV component from the IIS team in order to get Entourage to work with Exchange 2007 on Windows 2008 server.  If you’ve already installed the component:

http://learn.iis.net/page.aspx/350/installing-and-configuring-webdav-on-iis-70/  I've included steps below to uninstall it.  However, with the new Entourage 2008 Web Services Edition free upgrade, I would highly recommend upgrading your Entourage clients than continue to support WebDAV.  http://download.microsoft.com/download/2/0/C/20C4D3D0-C2B1-44F5-94B5-322BE47616D8/EWS-1305-EN.dmg

If you still require WebDAV version of Entourage in your environment though, here's what you'll need to do to get things right.  On the Exchange 2007 server the IIS WebDAV component is installed:

1)       Stop the W3svc service [this usually prevents the need to reboot]   net stop w3svc

2)       Uninstall the WebDAV component from Control Panel, Programs and Features

3)       Start the W3svc service  net start w3svc

4)       run the following commands from the Exchange Management Shell

Remove-OwaVirtualDirectory "exchange (default web site)"

-Refresh IIS manager to ensure the exchange virtual directory has been removed

New-OwaVirtualDirectory "exchange" -OwaVersion Exchange2003or2000 -VirtualDirectoryType Mailboxes -WebSiteName "Default Web Site"

5)       Ensure the proper permissions are configured on the Exchange virtual directory:

CAS role == Basic

MBX role == Windows Auth [as well as SSL settings with Require SSL unchecked]

6)       Run iisreset /noforce

The steps above show the basic setup requirements for Entourage:

On the CAS, the /Exchange virtual directory needs to have Basic authentication,

On the MBX, the /Exchange virtual directory needs to have Windows Auth enabled and the SSL requirement unchecked.

A great troubleshooting step from here is to enable Forms Based Authentication on the CAS for the OWA virtual directory in Exchange Management Console.  Once that is enabled, if you see redirection working properly for OWA through your browser, then most likely your server is configured correctly.

For example, for Entourage to work, you need to be able to access https://CAS/exchange from the Apple client you want to run Entourage from [which after getting redirected to the OWA FBA page you should be able to log in].  From the CAS, you should also be able to access http://MBX/exchange - If these two tests work, then you most likely need to visit

931350  You cannot connect to your mailbox on Exchange Server when you use Entourage for Mac

It’s better to work from https://CAS/exchange to http://MBX/exchange - if connecting to the CAS won’t work, then connecting the MBX over the Exchange virtual directory won’t work either.

-austinmc

When browsing through your Active Directory, you'll see Autodiscover objects in several places.  Here I'm going to help explain a little bit about the differences between these objects and some simple ways to troubleshoot them.  Using tools like ADSIedit or LDP can have far-reaching consequences.  Don't use those tools to modify or delete objects unless you fully understand those consequences.

There are 3 primary locations of Autodiscover labeled objects.

Here is the portion of Autodiscover in Active Directory called the AutodiscoverVirtualDirectory that is easily added and removed with the Exchange Command Shell functions:
Remove-AutodiscoverVirtualDirectory -Identity "<CASNETBIOS>\Autodiscover (Default Web Site)"
New-AutodiscoverVirtualDirectory -WebSiteName "Default Web Site"

Here is the portion of Autodiscover in Active Directory called the Service Connection Point [SCP] that is only created during installation of the CAS role.  Deleting this directly will require you to most likely uninstall the CAS role, replicate changes through your AD, then reinstall the CAS role.

Here is the portion of Autodiscover in Active Directory that configures Outlook Providers in regards to Outlook Anywhere.  The Get, Set, Remove and New-OutlookProvider commandlets are used to configure this.