Exchange shell: Using double quotes or single quotes in commands or scripts

Another frequently asked question about PowerShell/Exchange shell, and one that I myself had during the initial foray with the shell - what's the difference between using double quotes and single quotes in a shell command or script?

The biggest difference, and the only one I'm aware of, is the fact that using double quotes - e.g. "$mailboxes", expands the variable. (Note, if the variable has not been used/defined or doesn't have any value, you get no output.)

When using single quotes - e.g. '$mailboxes', it is treated as a string.

To see the difference in action:

$mailboxes = Get-Mailbox

Now that we have captured the value(s) of mailbox(es) in a variable (actually an array... it can have a single or multiple values. In this case, a single mailbox, if you only have one, or multiple mailboxes).

Next, let's get some output from this. First, let's try with single quotes:

Write-Host 'This is a list of all my mailboxes: $mailboxes'

What you get is simply:

This is a list of all my mailboxes: $mailboxes

Now let's try with double quotes:

Write-Host "This is a list of all my mailboxes: $mailboxes"

The output will list all your mailboxes, as seen below:

This is a list of all my mailboxes: Jane Doe John Doe....

I haven't found any side-effects of using double-quotes, except when you really want a particular variable/string to be treated as a string.

Released: ForeFront Security for Exchange SP1

ForeFront Security for Exchange SP1 follows Exchange Server 2007 SP1 out the door. FSE SP1 is compatible with Exchange Server 2007 SP1. It includes support for Windows Server 2008, IPv6, and improved content filtering.

Exchange Server 2007 SP1 and ForeFront Security for Exchange

- Before you upgrade Exchange Server 2007 to SP1, make sure you either upgrade ForeFront Security for Exchange to SP1, or uninstall it.
- If ForeFront Security for Exchange is upgraded to SP1, you must stop all ForeFront services before upgrading Exchange Server 2007 to SP1.

Download it here.

Released: Exchange Server 2007 SP1

Great news, in words of Exchange TAP Program Manager David Espinoza: "Exchange Server 2007 SP1 has left the building". The "pack of goodies" is Build 240.06 - download it here.

(Read the announcement on the team blog, with feedback from TAP customers, including Zenprise.)

Congratulations to the Exchange product team for shipping an unusual service pack, loaded with improvements in performance, functionality, plenty of new GUI admin interfaces in the EMC (more details in "New Exchange Management Console Features in Exchange 2007 SP1"), and quite a few new features.

On top of the list for most folks is the eagerly awaited Standby Continuous Replication (SCR), which uses the Database Continuous Replication technology to replicate Storage Groups from clustered/non-clustered sources to clustered/non-clustered targets. Designed to provide datacenter redundancy - the source and target can be on different subnets, in different AD Sites altogether.

Additionally, LCR - used to replicate Storage Groups to another volume on the same server - no longer requires 2-3x the disk IOPS on volumes where the replica is stored. LCR can also use the Transport Dumpster now (restricted to CCR earlier).

Support for Windows Server 2008 also allows Exchange Server 2007 to leverage the new Failover Clustering features in the OS - allowing CCR clusters to span across subnets, making CCR clusters across WAN links easier to deploy.

Exchange ActiveSync (EAS) comes with plenty of improvements as well - users with WinMo (i.e. Windows Mobile) 6 devices will be happy. Administrators will like the number of new settings in ActiveSync policies that allow increased control of devices. (Read previous post "Exchange Server 2007 SP1: Take control of your Windows Mobile devices").

OWA users get Public Folder access, S/MIME support, Personal Distribution Lists, server-side rules, and monthly calendar views, amongst other improvements.

Complete list of features available in "What's new in Exchange Server 2007 SP1".

Make sure you read the SP1 Release Notes before upgrading.

Clichés aside, this is the best Exchange service pack ever.

220 Welcome to a California mail server: Fighting spam with SMTP Banners

If you are interested in messaging and fighting spam, you probably watch the legal response to spam with some interest. Given the nature of email and the art of remaining anonymous or otherwise untraceable that spammers seem to have mastered, anti-spam laws were written off as largely ineffective, or even ridiculous. (The FTC begs to differ, in its report to Congress on the CAN-SPAM Act's effectiveness - PDF available here). Legislation and (its) enforcement can never be the sole approach to a problem mostly attributed to technology.

The much-talked about first conviction under the federal CAN-SPAM Act was handed out in California - to Nicholas Tombros in Los Angeles in 2004. Since then, quite a few spammers have had their date with the law, with the accompanying media brouhaha.

California anti-spam laws: California also has its own antispam laws - enacted as amendments to the Business and Professions Code. The rather lame one - Section 17538.4, allows California Attorney General to sue spammers, with a list of IFs that make it more like a "License To Spam". Section 17538.45 is the one of interest, aimed at protecting email service providers from spammers. Email service providers can file civil suits against spammers and claim greater of the following amounts:
- the actual monetary loss suffered by reason of that violation
- liquidated damages of $50 per message initiated or delivered, up to a maximum of $25,000 per day.

Any organization that provides the ability to send or receive email to registered users through equipment located in California (and is an "intermediary" in sending/receiving email) is an email service provider for the purpose of this law.

Interesting, as technology-related legislative action always is.

If your mail servers are located in California (and even if they are not... ), it makes sense to change the SMTP banner (SMTP 220 response) to give notice to a sender that your system should not be used to send unsolicited electronic mail advertisements.

The California Business and Professions Code Section 17538.45 states:

(3) (A) In any action brought pursuant to paragraph (1), the electronic mail service provider shall be required to establish as an element of its cause of action that prior to the alleged violation, the defendant had actual notice of both of the following:

(i) The electronic mail service provider's policy on unsolicited electronic mail advertising.

(ii) The fact that the defendant's unsolicited electronic mail advertisements would use or cause to be used the electronic mail service provider's equipment located in this state.

(B) In this regard, the Legislature finds that with rapid advances in Internet technology, and electronic mail technology in particular, Internet service providers are already experimenting with embedding policy statements directly into the software running on the computers used to provide electronic mail services in a manner that displays the policy statements every time an electronic mail delivery is requested. While the state of the technology does not support this finding at present, the Legislature believes that, in a given case at some future date, a showing that notice was supplied via electronic means between the sending and receiving computers could be held to constitute actual notice to the sender for purposes of this paragraph.

Let's leave the legal interpretation of laws to those who practice law. Regardless of whether your organization intends to take legal action against spammers or not, one of the important principles of information security is having policies in place and communicating them clearly. Not only does it demonstrate your organization's intent, it can be a potential deterrent for folks who may otherwise claim ignorance of such policies.

(While we're on the subject of SMTP banners, for historical context, also take a look at Paul Hobbes & John Levine's draft from 1998 titled "Anti-UBE and Anti-UCE Keywords in SMTP Banners". Much later, a SMTP extension was also proposed to include such information - RFC 3865 - A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension.)

Changing the SMTP banner: Assuming the policy is in place, the SMTP banner can be changed easily to communicate it, as hosted email security and compliance services provider Postini (acquired by Google not too long ago) does.

220 Postini ESMTP 11 y6_12_2c0 ready. California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.

On Exchange Server 2003/2000 or if using Windows Server's SMTP service component on SMTP gateways, the banner text can be changed by setting the IIS Metabase value ConnectResponse, using any Metabase editor or the adsutil.vbs script that ships with IIS (in the Inetpub\AdminScripts directory by default).

cscript adsutil.vbs set smtpsvc/1/ConnectResponse "220 California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements."

Note, the numeric value 1 after smtpsvc/ in the above command refers to the SMTP Virtual Server ID. Each SMTP VS has one, the default/first one starting at 1. To get a list of SMTP Virtual Servers using adsutil.vbs:
adsutil.vbs enum /p smtpsvc

Exchange Server 2007 makes changing the banner a relatively simple task. Note, the banner should start with the SMTP response code 220. Fire up the shell:

Set-ReceiveConnector "Connector Name" -banner "220 (Optional: Server.domain.com). California Business and Professions Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements."

That wasn't too difficult, was it? If that simple banner change deters a a single spammer from victimizing your users, and in the process buys you the legal ammunition (that may some day help your organization take legal action, should it decide to.... ), is it worth it?

Critical Apple Mail vulnerability reintroduced in Leo

"In a world where PCs constantly do battle with viruses and malware, Mac OS X is a sea of tranquility", Apple likes to remind the world about its OS X operating system.

Interestingly, Computerworld's Gregg Keizer reports about a critical vulnerability in Apple Mail that was fixed in OS X Tiger has been reintroduced in its brand new Leopard OS. More in "Once-fixed bug pops up again in Leopard's Mail" on Computerworld.com.

The vulnerabilities in Apple's own QuickTime media player are not limited to Windows boxes (running QuickTime) either.... - the Mac is vulnerable as well.

I like Leo - it's a great-looking OS, paired with well-designed boxes. However, when it comes to security, no single vendor has the magic pill. As far as number of vulnerabilities go, and the time taken to fix these, Microsoft does seem to have a better record imo. (Read previous post "Numbers talk: Vista most secure OS of all?")

Exchange Server 2007: How many logs hath thee?

A recent question got me thinking about this, thanks to a fellow MCT. How may logs does Exchange Server 2007 have? There are the known logs, carried over from previous versions (albeit with some differences), and a slew of new logs that one deals with.

So let's take a quick look at the number of logs the mighty new (well, almost... ) Exchange Server 2007 has. Pointers to previous posts or relevant Exchange documentation are provided throughout this post for additional information.

1. Setup Log: Exchange Server 2007 logs detailed setup-related information to the Setup log. Two log files are created in \ExchangeSetupLogs directory - 1) ExchangeSetup.msilog logs events related to extraction of Exchange files from the installer 2) ExchangeSetup.log has details about every step of the setup, including system status, pre-requisite checks, installation, configuration, etc. A shell script Get-SetupLog.ps1 (in the \Exchange Server\Scripts directory) is available to review setup information. More details in 'Verifying an Exchange 2007 Installation" in product documentation.

2. Transaction logs: These are the familiar ESE Database write-ahead logs that we've seen since as long as Exchange's ESE Databases have been around. These contain information about changes to the Exchange (Mailbox and Public Folder) Databases.

In addition to the Mailbox and Public Folder Databases, Exchange Server 2007 also uses ESE databases for transport queues.

Transaction logs used to be 5 Mb. in previous versions. In Exchange Server 2007, the size has been reduced to 1 Mb. to accommodate new replication features. It's important to note that transaction logs belong to a Storage Group, not a particular Mailbox or Public Folder Database.

Unlike most other logs mentioned in this article, transaction logs don't contain any readable information that can be readily used for troubleshooting Exchange issues. However, these are perhaps the most important type of logs for the health of an Exchange server. More information about transaction logs in "Understanding transaction logging".

Transaction log-related configuration changes can be made using the Set-StorageGroup shell command. Basically, there's not much to configure, except changing the path to move transaction logs to an alternate location - a different folder or on another volume. You can enable Circular Logging in scenarios where up-to-the-minute restores are not required, or during bulk mailbox moves where generation of an extraordinary number of log files is anticipated.

Parameters and defaults:
LogFolderPath: location of transaction logs for a Storage Group
CircularLoggingEnabled: false
LogFilePrefix: View-only parameter. Prefixes are added to transaction log file names, starting with E00 for log files belonging to the first Storage Group on a server, incremented sequentially to E01, E02, etc. for subsequent Storage Groups.
LogFileSize: View-only parameter. 1024 (file size in bytes).
CopyLogFolderPath: location of transaction logs for LCR replicas

3. Message Tracking Logs: Message Tracking logs tell us where a message is at every step of the way in the transport pipeline. These are invaluable for troubleshooting mail flow problems. Many third-party reporting tools also use these as fodder to generate great-looking reports about messaging activity in Exchange environments. (Read previous post "Exchange Server 2007: Message Tracking from the command line")

Message Tracking logs exist on mailbox and transport servers (Hub and Edge Transport) and are enabled by default. The relevant parameters (listed below) can be viewed/modified using
Get-TransportServer/Set-TransportServer commands. The Mailbox server equivalents are Get-MailboxServer/Set-MailboxServer.

Parameters and defaults:
MessageTrackingLogPath: \Exchange Server\TransportRoles\Logs\MessageTracking
MessageTrackingLogEnabled: true
MessageTrackingLogSubjectLoggingEnabled: true
MessageTrackingLogMaxAge: 30.00:00:00 (30 days)
MessageTrackingLogMaxFileSize: 10Mb
MessageTrackingLogMaxDirectorySize: 250Mb

Access: Get-MessageTrackingLog shell command, or the Message Tracking tool in EMC.


Figure 1: The EMC allows you to enable/disable Message Tracking and Connectivity logs, and set or change paths where the log files are stored for these, in addition to SMTP Send and Receive logs. To access the above dialog box, expand Server Configuration | Hub Transport | select a Hub Transport server | select Properties | go to Log Settings tab.

4. SMTP Send and Receive Logs (aka "Protocol" logs): Exchange Server 2003/2000 have a single SMTP log for a SMTP Virtual Server, configured from SMTP Virtual Server properties in Exchange System Manager. Exchange Server 2007 splits these into SMTP Send and SMTP Receive logs for a transport server. Gone is the per-SMTP Virtual Server granularity
(the equivalent would have been per-Receive Connector and per-Send Connector logs... note to Devin Ganger: Yes, Receive Connectors are not the same as SMTP Virtual Servers - but they're close enough conceptually to invite comparisons... :). You can still enable/disable logging for a Send or Receive Connector. For more details about SMTP Send and Receive Logs, read previous post "Exchange Server 2007: Logging SMTP Protocol Activity".

Most settings for SMTP Send and Receive Logs are stored in the transport server configuration, just like Message Tracking Logs. However, logging can be enabled/disabled on each individual Send and Receive Connector by using
Set-SendConnector and
Set-ReceiveConnector commands.

Location:
SMTP Send Logs: \Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend
SMTP Receive Logs: \Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive

Send and Receive Connector parameter
ProtocolLoggingLevel: None (to enable it, set it to verbose in Connector properties)

Transport Server parameters:
SendProtocolLogMaxAge: 30.00:00:00
SendProtocolLogMaxDirectorySize: 250MB
SendProtocolLogMaxFileSize: 10MB
SendProtocolLogPath: \Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend

ReceiveProtocolLogMaxAge: 30.00:00:00 (30 days)
ReceiveProtocolLogMaxDirectorySize: 250Mb
ReceiveProtocolLogMaxFileSize: 10Mb
ReceiveProtocolLogPath: \Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive

5. Agent Logs: Actions taken by anti-spam agents are logged in Agent Logs, and are a very welcome new addition to Exchange's messaging hygiene/anti-spam features. Agent logs are enabled by default. More about Agent Logs in previous post "Exchange Server 2007: Managing And Filtering Anti-Spam Agent Logs".

The following agent log parameters are not configurable.
Location: \Exchange Server\TransportRoles\Logs\AgentLog
File Size: 10 Mb
Directory Size: 250 Mb
Max Age: 30 days

Access: Agent logs can be accessed using the
Get-AgentLog shell command. There are no GUI interfaces to parse/search agent logs in the EMC.

6. Connectivity Logs: Records information about outbound SMTP connectivity to mailbox servers, smarthosts, or destination domains, including source queue, destination (mailbox server, smarthost, or domain), DNS resolution, connection failures, transmitted messages and bytes. Note, this is not SMTP (protocol) logging, but a more network-centric view of outbound connections. Connectivity Logs are not enabled by default. More details in "Managing Connectivity Logging".

Parameters and defaults:
ConnectivityLogEnabled: false
ConnectivityLogMaxAge: 30.00:00:00
ConnectivityLogMaxDirectorySize: 250Mb
ConnectivityLogMaxFileSize: 10Mb
ConnectivityLogPath: \Exchange Server\TransportRoles\Logs\Connectivity

7. Routing Table Logs: A snapshot of the transport server's routing table is logged when the transport service starts, when a routing configuration change is detected, and at fixed interval (12 hours by default, configurable by modifying EdgeTransport.exe.config file). More details in "Managing Routing Table Logging".

Parameters and defaults:
RoutingTableLogMaxAge: 7.00:00:00 (7 days)
RoutingTableLogMaxDirectorySize: 50Mb
RoutingTableLogPath: \Exchange Server\TransportRoles\Logs\Routing

8. Messaging Records Management (MRM) Logs: Exchange Server 2003/2000's Mailbox Manager feature, which is often compared to Managed Folders in Exchange Server 2007, sends a report to a designated mailbox about actions taken. It also has a Report Only mode. The Managed Folders Agent, which is responsible for applying Managed Folder Mailbox Policies to mailboxes, does no such reporting. However, it does provide detailed MRM logs, which can be used to generate the required reports.

Messaging Records Management is more than simply cleaning up mailboxes. From a compliance standpoint, MRM logs are more important than others in the list. As such, it may be required to archive these for a longer period, depending on organizational policies. The MRM log defaults reflect this.

More details in "How to Configure Messaging Records Management Logging".

Parameters and defaults:
LogPathForManagedFolders: \Exchange Server\Logging\Managed Folder Assistant
LogFileAgeLimitForManagedFolders: 00:00:00
LogDirectorySizeLimitForManagedFolders: unlimited (per-Database, log files for the a Database have the same prefix. The limit is for log files for each Database, not a cumulative size limit for the directory)
LogFileSizeLimitForManagedFolders: 10MB
MRM logs are disabled by default. To enable MRM logging, set any of the following parameters to true.
RetentionLogForManagedFoldersEnabled: False (Set to $true to enable logging of messages processed because they reached the retention limits)
JournalingLogForManagedFoldersEnabled: False (Set to $true to enable logging of items in Managed Folders are journaled)
FolderLogForManagedFoldersEnabled: False (Set to $true to log creation or deletion of Managed Folders by MFA)
SubjectLogForManagedFoldersEnabled: False (Set to $true to log subject of messages being processed by MFA)

9. IIS Logs: On Client Access Servers, HTTP activity for OWA and EAS access is logged in IIS logs. Configuration of IIS logging is controlled from the IIS Manager console. IIS activity can be logged in a number of different log file formats:
- the default W3C Extended (ASCII text, fields customizable)
- IIS (fixed field, ASCII text, not customizable)
- NCSA Common (fixed field, ASCII text, not customizable)
- and ODBC (logged to ODBC-compliant databases like Microsoft Access and SQL Server, resource-intensive).

Path: %systemroot%\System32\LogFiles\W3SVC1 (where 1 is the web site ID in IIS Metabase)
Max File Size: Unlimited. Log files rolled over daily. Setting can be changed to roll over log files based on file size.
Max Directory Size: unlimited (Cannot be set. It's important to remove/archive these periodically.)

More info about configuring IIS logs in "Configuring IIS Logs (IIS 6.0)".

IIS Logs and Exchange ActiveSync: Exchange Server 2007 also has a cmdlet/task for extracting ActiveSync data from IIS logs and generating reports - Export-ActiveSyncLog. More info about EAS reporting in Exchange ActiveSync Reporting Services.

10. POP3 and IMAP4 Protocol Logs: Protocol logging for POP3 and IMAP4 protocols is disabled by default. This can be enabled by editing the related config files. The logs are not kept around for too long - the default is 24 hours, just enough to allow for troubleshooting recent issues. In most environments, these logs lose value quite rapidly - keeping them for extended periods is unnecessary, unless mandated by compliance policies in your organization.

POP3 log configuration: Microsoft.Exchange.Pop3.exe.config file
IMAP4 protocol log: Microsoft.Exchange.Imap4.exe.config file
Location: \Exchange Server\ClientAccess\PopImap

Parameters and defaults:
ProtocolLog: false (disabled by default, change this key to true in above config files for each protocol to enable logging)
AgeQuotaInHours: 24 hours
SizeQuota: 10000000 (10 million bytes / approx 9.54 Mb)
PerFileSizeQuota: 1000000 (1 million bytes / approx 976 Kb)

11. Certificate Logging: Certificate logs can be used to troubleshoot certificate-related problems for SMTP, POP3 and IMAP4 protocols. Though certificate-related issues are logged in the Application Event Log,
Exchange Server 2007 SP1 adds the functionality to log more detailed information to a log file. In addition to the above, verbose information can be exposed/output in the Exchange shell when using the Get-ExchangeCertificate, New-ExchangeCertificate, and Enable-ExchangeCertificate commands, by adding an xml snippet to the Powershell.config file. The configuration options are discussed in "How to Enable Certificate Logging" in Exchange documentation.

12. Cluster Log: In clustered environments, Windows Server 2003/2008 OS maintains a cluster log with detailed information about cluster events like initialization, node addition/removal, resource states, failovers, etc. The Cluster service also logs important event information to Windows event logs. However, for in-depth troubleshooting and diagnostics, the cluster log has the beef. More information about the Cluster log in "Cluster Log Basics".

Location: %systemroot%\Cluster

13. Pipeline Tracing Logs: Pipeline tracing is used to troubleshoot transport agents. It logs email messages as they traverse the transport pipeline, including message content and actions taken by transport agents. Pipeline tracing is configured using the Set-TransportServer command.

More info in "Using Pipeline Tracing to Diagnose Transport Agent Problems".

Parameters:
-PipelineTracingEnabled: false (set to $true to enable Pipeline Tracing)
- PipelineTracingPath: location of Pipeline Tracing logs, default \Exchange Server\Transport Roles\Logs\PipelineTracing
- PipelineTracingSenderAddress: Use internal or external sender's SMTP address to log messages sent by that address. Only messages sent by that address are logged, including message content. Use "<>" to log system messages like OOFs, DSNs, journal reports, etc. (Logs *all* server-generated messages a Hub Transport server sees - can place significant load on the server).

14. Application Event Log: Last, but not the least, Exchange logs plenty of information to the Application Event Log. The level of logging is set to lowest for most Exchange services and processes. Each event log entry has a numeric identifier - the Event ID, and a well-defined structure. Events in Windows event logs can be accessed using the Event Viewer console, which provides a rich UI for viewing, searching and filtering event log entries. Other acess methods include interfaces like WMI. Windows PowerShell (and therefore, the Exchange shell) also provide a way to quickly access event log information from the command-line, using the Get-EventLog command.

Diagnostic Logging and Exchange Server 2007: Every once in a while you run into issues that require more information from different Exchange services/processes, than what's logged to the Application event log by default, in order to troubleshoot them. Such detailed logging is not required for normal operations.

Diagnostic Logging levels: You can change the level of detail Exchange services/processes log to the Application Event Log when diagnostic logging is enabled. The different levels:
0 - Lowest
1 - Low
3 - Medium
5 - High
7 - Expert

If left turned on, diagnostic logging can quickly flood event logs, making it difficult to locate other important events or having them purged from logs based on size and age restrictions. Bump up diagnostic logging to troubleshoot issues, and remember to turn it off once done.

To bump up diagnostic logging for a particular Exchange process/service (here's a list of processes with configurable event log levels) - the Categorizer in this case, to level 7 (expert):

Set-EventLogLevel MSExchangeTransport\Categorizer -Level 7

More information about diagnostic logging in "Diagnostic Logging for Exchange Processes".

In addition to the Application event log, the OS also maintains Security and System event logs.



Are you log happy?: By all accounts, Exchange Server 2007 is a log-happy product, providing a rich set of logs for its different features, services and processes. In many cases , parsing these logs is made much easier than previous versions, thanks to the Exchange shell commands and changes to logged fields/formats.

Whereas logs like Windows Servers' event logs provide a rich user interface (further enhanced in the new Event Viewer in Windows Server 2008) and access methods, and others like anti-spam Agent Logs can be accessed and parsed easily using the Exchange shell, there are plenty of logs in the above list that are not accompanied by any specific user interfaces or shell commands. In particular, the SMTP (Protocol) Send and Receive log is one such that is accessed frequently by administrators while troubleshooting mailflow issues. Hopefully, future versions of Exchange will include the necessary shell commands to access and parse these.

Nevertheless, it is great to have access to more information for troubleshooting and operations, provided you know where to look.

TechNet Chats: Q&A With the Exchange MVP Experts

Microsoft is holding another round of Q&A chats with Exchange Server MVPs. These were fun the last time (transcripts here), so if you have questions about Exchange Server - planning issues, deployments, best practices, security, HOW TOs, etc., and want answers from Exchange MVPs - pick a convenient time from the following.

Q&A With the Exchange MVP Experts
We invite you to attend a Q&A with the Microsoft Exchange Server MVPs. In this chat Exchange MVPs will be on hand to answer your questions about Exchange Server, Outlook and Exchange for Small Business Server. So if you are thinking of upgrading to Exchange Server 2007 or have questions about Exchange Server 2003 we hope you can join us for this informative online chat!

December 5, 2007 - 10:00 AM Pacific Time - Add To Calendar
December 12, 2007 - 5:00 PM Pacific Time - Add To Calendar

Enter TechNet Chat Room (for both events)

Messaging Records (Mis)Management at the White House

ORDERED that defendants shall preserve media , no matter how described, presently in their possess or under their custody or control, that were created with the intention of preserving data in the event of its inadvertent destruction. Defendants shall preserve the media under conditions that will permit their eventual use, if necessary, and shall not transfer said media out of their custody or control without leave of this court.

In the continuing saga of what can be seen as MRM (Messaging Records Mis-Management), U.S. District Judge Henry H. Kennedy has issued the above temporary restraining order (PDF) blocking the White House from destroying backups of their email. The order is the result of a motion filed by the watch-dog organization Citizens for Responsibility and Ethics in Washington (CREW).

The story: About 5 million missing messages from March 2003 to October 2005, a critical period that includes the Iraq invasion, the 2004 election and hurricane Katrina. (For more details, read previous post "Email Archiving and Compliance: Learning from email issues that plague the White House")

Washington Post's Dan Froomkin has more in his column "Where are the emails?".

Excerpt:

"The judge's order 'should stop any future destruction of e-mails, but the White House stopped archiving its e-mail in 2003 and we don't know if some backup tapes for those e-mails were already taped over before we went to court. It's a mystery,' said Meredith Fuchs, a lawyer for the National Security Archive."

Restricting Messaging Records Management to a particular message type

One of the frequently asked questions related to Exchange Server 2007's Messaging Records Management is: how do I purge only specific type of items from a particular default or custom Managed Folder, or the entire mailbox? For instance, in many scenarios its acceptable to purge messages from a particular folder or the entire mailbox after a certain number of days, but you don't want to touch users' Contacts, Notes, Calendar items, etc.

I've hinted at how to accomplish this in a previous post (read "Managed Folders: How to apply different Managed Content Settings to Default Folders") as a sidebar item. This post directly addresses such questions and scenarios.

Let's say you want to purge items that are older than a certain number of days from the entire mailbox, without touching particular type of items.

To accomplish this:

Create a new Managed Default Folder called "EntireMailbox-Purge365Days" (or pick a name that describes this better... ). In the Default folder type drop-down, select All other folders in the mailbox

All other folders in the mailbox, and default folders

If the Entire Mailbox Managed Folder, or any other instance of a Managed Folder created using All other folders in the mailbox is used in a Managed Folder Mailbox Policy, it applies to the entire mailbox (including all Default Folders and any Custom Folders created by Exchange or by the mailbox user), except any default or custom Managed Folders included in the same Managed Folder Mailbox Policy.

Scenario 1: A policy that includes a Default Folder of type All other folders in the mailbox (including the pre-canned Entire Mailbox Default Folder) applied to a user, no other Default Folders are included in that policy. The policy applies to the entire mailbox, including all Default and Custom folders.


Figure 2: A Managed Folder Mailbox Policy applied to Entire Mailbox also impacts any custom folders created by the mailbox user that are not explicitly included in the policy.

However, if you have restricted the message type to "E-mail", the policy will only take action on email items in those folders.

Scenario 2: A policy that includes a Default Folder of type All other folders in the mailbox (including the pre-canned Entire Mailbox Default Folder) is applied to a user, policy also includes other Default Folders such as Deleted Items, Inbox, etc.
The result: The Managed Content Settings for the "entire mailbox" Default Folder applies to all Default and Custom Folders, but not to the ones you explicitly linked to the same policy.

Create new Managed Content Settings for the new folder. Under message type, select "E-mail".



You cannot select multiple message types - the only choices are selecting All Mailbox Content, or a specific message type. If you want to apply settings for different message types, create additional Managed Content Settings for the Default Folder and select other message type like Faxes, RSS Items, Missed Calls, etc. - one message type per Managed Content Settings.

Add this new Managed Default Folder to an existing Managed Folder Mailbox Policy, or create a new policy.

Apply the policy to appropriate users if not already applied. (Read previous post "Applying Managed Folder Policy to more than one user")

Ensure the Managed Folder Assistant is scheduled to run. (Read previous post "Exchange Server 2007: Why aren't Managed Content Settngs applied?")

 Related posts:
- Managed Folders: How to apply different Managed Content Settings to Default Folders
- Applying Managed Folder Policy to more than one user
- Exchange Server 2007: Why aren't Managed Content Settngs applied?

Released: Windows PowerShell 2.0 CTP

For all those eagerly awaiting developments on the shell front, Microsoft has released a Community Technology Preview (CTP) of Windows PowerShell 2.0.

PowerShell 2.0 boasts some interesting (many frequently requested) features, including:
- remoting (ability to execute commands on remote computers)
- "a very early alpha version" of the Graphical PowerShell utility
- background PowerShell jobs that run without interaction with the console (including ability to trigger/run these on remote computers)
- ability to write your own commandlets in PowerShell rather than having to use compiled VB.NET or C# code
- 24 new commandlets, improved WMI and ADSI support, and quite a few other features listed in "What's New in CTP of PowerShell 2.0" on the PowerShell team blog.

The Graphical PowerShell requires .Net Framework v3.0.

Download the Windows PowerShell 2.0 CTP from here, and don't rush to install it on your production Exchange Server 2007 servers just yet - it's still a beta product.

AD Explorer: A better ADSIEdit than ADSIEdit

Came across this useful Active Directory tool called AD Explorer, thanks to fellow Zenpriser Tariq Hamirani. Created by Bryce Cogswell and Mark Russinovich, it's another one of those cool SysInternals tools that came with Microsoft's acquisition of their company Winternals.

AD Explorer is a better ADSIEdit than ADSIEdit. It lets you add AD locations (containers/objects) as favorites to be able to easily navigate to the same location, maintains a history of the locations you've visited in an AD tree and navigate forward/backward to them, and also lets you create snapshots of your AD data for offline viewing/tinkering.

Download this free utility and take it for a spin - it's a single file all of 230Kb (the download has a license agreement and a 50K help file in CHM format).

HOW TO: Hide Distribution Group membership

Exchange Server 2003's ADUC extensions made hiding a Distribution Group's membership a trivial task, accomplished by right-clicking a group, selecting Exchange Tasks and selecting Hide Membership.


Figure 1: The Exchange Tasks wizard in ADUC provides an option to hide Distribution Group membership in Exchange Server 2003

As the task suggests, it hides the group's membership in Outlook Address Book/GAL. It also prevents users from clicking the + link that appears before a Distribution Group when composing a new message, and expanding the group so messages are sent individually to all members rather than the DG.


Figure 2: Distribution Groups that have their membership hidden cannot be expanded in Microsoft Outlook

The Hide Membership task available from Exchange Tasks denies Read Property permission for the Members attribute, to the Everyone group. This also prevents Administrators trying to manage the group from seeing the group's members.


Figure 3: Hiding a Distribution Group makes changes to the Distribution Group's ACL

Hiding Distribution Group membership in Exchange Server 2007

Hiding Distribution Group membership is not supported in Exchange Server 2007. There is no option to hide Distribution Group membership in the console, nor a single parameter you can flip using the shell.

Nevertheless, you can prevent users from expanding the group in Microsoft Outlook, and hide the group's Member attribute so it's not visible in the properties pages in Outlook or OWA. The caveat - it's not a way to hide membership completely, as noted later in the post.

Adding Deny ACE for the Members property

Use the following command to deny the ReadProperty permission for the Distribution Group's Members property to a particular user or Security Group (Remember the security best practice - add users to Security Group -> assign permissions to Security Group?):

Add-ADPermission "Distribution Group Name" -user "User or Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Note, to simulate what Exchange Server 2003's Hide Membership task does, you can use the Everyone group in the -users parameter. This hides membership from the EMC as well, but the shell can still show membership using the Get-DistributionGroupMember command.

Once the permission is added, clicking on the + link in Microsoft Outlook produces the following not-so-descriptive error message, and the user is prevented from expanding the Distribution Group.


Figure 4: With the Deny ACE in place, Outlook users get an error when trying to expand the Distribution Group. Click here to see a larger image

Additionally, membership of the group is not revealed in the group's properties in the Address Book/GAL.

Adding Deny ACE using the GUI

If you've already used the shell to add the deny ACE, you can skip the following procedure and head to the next section.

For the console/GUI fans amongst us or those who simply haven't developed an intimate relationship with the shell (hopefully the following will make you a convert... :), ADSIEdit is your friend. Fire it up:

1. Navigate to the Distribution Group's properties
2. Select the Security tab
3. Click Add
4. Select the user or group you want to deny permission to (you can use the Everyone group to simulate what Exchange Server 2003 does)
5. Click OK
6. click Advanced (wait... ) to open Advanced Security Settings
7. Select the Permissions tab
8. Select the user or group if not already selected
9. Click Edit to open the Permissions Entry properties for the selected user/group
10. Select Properties tab
11. Click on the "Deny" checkbox for the Read Members property so it is checked.
12. Click OK to close the Permissions pages.
13. Click OK to close the Advanced Security Settings pages
14. Click OK to close the Properties dialog box

Inspecting any non-inherited permissions and removing the Deny ACE

To determine any modifications to the AD permissions for the Members property:

Get-ADPermission "Distribution Group Name" | where {$_.Properties -like "member"} | fl

To remove the Deny permission on the Member property for a Distribution Group, use the Remove-ADPermission command:

Remove-ADPermission "Distribution Group Name" -user "User/Security Group Name" -Deny -AccessRights ReadProperty -Properties Member

Prevent Delivery Reports from Distribution Group

Users can send a message to the Distribution Group with a Delivery Report requested, which can reveal the group membership.

To prevent a Delivery Report from being sent to the originator (consider this carefully, you may want senders to receive delivery reports if messages are not delivered to members of certain Distribution Groups. You can also enable delivery reports to the group Manager only.), use the following command:

Set-DistributionGroup "Distribution Group Name" -ReportToOriginatorEnabled $false

Once this is done, Exchange simply sends a Distributtion Group expanded/delivered to DG message in the Delivery Report, if one is requested, without revealing the group's members.


Figure 5: Preventing Delivery Reports to originator returns a "delivered to DG" message when Delivery Reports are requested

Hiding group membership in OWA

Membership of the Distribution Group can be viewed in OWA (OWA 2007). As reader Bart points out, this is easily fixed by flipping the hideDLMembership attribute to TRUE. At first look, the attribute doesn't seem to be exposed by the Exchange shell. You can use your LDAP/AD tool of choice, including ADSIEdit, to modify it.


Figure 6: Flipping the Distribution Group's hideDLMembership attribute to True in ADSIEdit

With the attribute set to true, group membership is no longer revealed.

Yes, this means this workarounds mentioned above can be used to:

- Hide Distribution Group membership from Outlook users
- Prevent Outlook users from expanding the Distribution Group when composing new messages
- Hide Distribution Group membership from OWA users
- Prevent Delivery Reports from revealing group membership

The caveat: These workarounds succeed in hiding membership by examining the Distribution Group (or sending a message to it). This may meet your requirements for hiding group membership. However, you can examine the Member Of property page of a recipient and see which groups he/she is a member of. Agreed, this is not a convenient way of discovering group membership— particularly if you have a large number of recipients. Nevertheless, from a security standpoint, this does mean there's no hiding of group membership.