Outlook Spy 2.15 is Outlook 2010-compatible

Didn't notice earlier— one of my favorite Outlook/Exchange tools is now compatible with Outlook 2010. Outlook Spy is primarily a tool for Outlook/Exchange developers, but Exchange administrators also find it useful. It allows you to look under the hood of mailboxes and messages. Created by Dmitry Streblechenko, an Outlook MVP, Outlook Spy has been on my list of "must have Exchange tools" for as long as I can remember. Released in November 2009, the latest version of Outlook Spy (v2.15) adds Outlook 2010 compatibility.

You can download Outlook Spy 2.15 from Dmitry's web site. Registration for a single user license is $49.99. It's been worth every penny and more for me.

I also like the free MFCMapi tool on Codeplex - Microsoft's open source community site where you'll find a lot of useful tools and apps along with the source code. MFCMapi is a compact executable (760-873K) and doesn't require installation. It was created by Microsoft's Stephen Griffin. It's available in both 32-bit and 64-bit versions.

Bulk mailbox creation: Import passwords from a file

Automating bulk mailbox creation required fairly advanced scripting skills in Exchange 2003/2000. Thanks to the Exchange Management Shell (aka "the shell") in Exchange 2010 and 2007, this task is greatly simplified. It doesn't require any advanced scripting skills and it can be accomplished by relative newcomers to Exchange Server with very little knowledge of the shell.

Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell shows you how to create bulk mailboxes using user data imported from a CSV file. A related post— Bulk mailbox creation revisited: Adding Active Directory attributes shows you how additional Active Directory attributes not included in the New-Mailbox/Set-Mailbox cmdlets can be populated.

When creating mailboxes using the New-Mailbox cmdlet, Exchange Shell requires the password to be of type System.Security.SecureString, derived from the SecureString class in the dot net framework. In the example in Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell, we use the same password for all accounts. We also prompt the admin to enter that password using the Read-Host cmdlet, as shown below:

$Password=Read-Host "Enter Password" -AsSecureString

When the admin running the command or script enters the password, powershell masks the password by displaying a * for each character entered.

One frequently asked question when discussing bulk mailbox creation is: how do I import passwords from a text file? Of course, saving passwords in a text file isn't very secure, but there may be cases where you need to do this temporarily— particularly when you want to create mailboxes/user accounts in bulk and don't want to assign the same password to all accounts. When doing so, it's recommend to set the account to change password on next logon. There may also be other scenarios where you need to import passwords from a text file, so I'll leave the security aspect of this up to you.

The first step to importing passwords from the text file is to add it as an additional column or field in the file. For example:

Alias,Name,UPN,Password
User_One,User One,userone@yourUPNsuffix.com,P@ssw0rd1
User_Two,User Two,usertwo@yourUPNsuffix.com,P@ssw0rd2
User_Three,User Three,userthree@yourUPNsuffix.com,P@ssw0rd3

If you try to use the same command as shown in the previous post, and simply add the parameter -password and the value $_.password in the code block, it'll fail.

Import-CSV CreateRecipients.csv | foreach {new-mailbox -alias $_.alias -name $_.name -userPrincipalName $_.UPN -database "Mailbox Database" -org Users -Password $_.password}
Cannot process argument transformation on parameter 'Password'. Cannot convert the "P@ssw0rd1" value of type "System.String" to type "System.Security.SecureString".
+ CategoryInfo : InvalidData: (:) [New-Mailbox], ParameterBindin...mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,New-Mailbox

Converting a string to a SecureString
To use the password field imported from the CSV file, you must first convert it to a SecureString. You can convert a string to a SecureString using the ConvertTo-SecureString cmdlet. When using the ConvertTo-SecureString cmdlet, you must specify that the source string is provided as cleartext by using the AsPlainText switch (not to be confused with the plaintext message format). The cmdlet also requires that you specify the Force switch to confirm you really want to do this— yes, you've just provided your consent to convert a plaintext string to a SecureString!

The modified command looks something like this:

Import-CSV CreateRecipients.csv | foreach {New-Mailbox -Alias $_.alias -Name $_.name -UserPrincipalName $_.UPN -Database "Mailbox Database" -Org Users -Password (ConvertTo-SecureString $_.password -AsPlainText -Force)}

To enforce a password change on next logon, add the ResetPasswordOnNextLogon parameter to the command:

Import-CSV CreateRecipients.csv | foreach {New-Mailbox -Alias $_.alias -Name $_.name -UserPrincipalName $_.UPN -Database "Mailbox Database" -Org Users -Password (ConvertTo-SecureString $_.password -AsPlainText -Force) -ResetPasswordOnNextLogon $true}

Export and Import Content Filter Words or Phrases

In Exchange 2010 and Exchange 2007, you can add custom words or phrases as good or bad words to modify the Spam Confidence Level (SCL) assigned to messages. Messages with a good word or phrase are assigned an SCL of 0 and bypass other antispam agents that fire after the Content Filtering agent. Messages with a bad word are assigned an SCL of 9, and any configured action (delete/reject/quarantine) is taken based on the Content Filtering configuration.


Figure 1: Adding a custom word or phrase to Content Filtering configuration

To add a good or bad phrase to the custom words list using the EMC:

1. Go to Organization Configuration | Hub Transport | Anti-spam tab
   
2. Select Content Filtering and click Properties in the action pane
   
3. In Content Filtering Properties, select the Custom Words tab
   
4. Add a word or phrase in the following fields as required:
   • Messages containing these words or phrases will not be blocked:To add a good word or phrase, type it in this field
     
   • Messages containing these words or phrases will be blocked, unless the message contains a word or phrase from the list above: To add a bad word or phrase, type it in this field.
   
   

To add a word or phrase using the shell, besides the actual word or phrase, you must also specify the influence:

Add-ContentFilterPhrase "bad word" -Influence Badword

You can get a list of words or phrases added to Exchange by using the Get-ContentFilterPhrase cmdlet:

Get-ContentFilterPhrase | Select phrase,influence

Exporting and Importing Custom Words and Phrases
On the Edge Transport server, configuration information is stored in the local instance of Active Directory Application Mode (ADAM) on Windows Server 2003. In Windows Server 2008, ADAM is renamed to Active Directory Lightweight Directory Service (ADLDS). Unlike Exchange Server configuration information stored in Active Directory, which is replicated to all domain controllers in the AD forest, Edge Transport configuration information stored in ADAM/ADLDS is not replicated to other Edge Transport servers.

You can configure an Edge Transport server using a cloned configuration. See Using Edge Transport Server Cloned Configuration.

You can also export only the content filter phrases from one Edge Transport and import it to another Edge Transport server. To export the phrases, use the Get-ContentFilterPhrase cmdlet:

Get-ContentFilterPhrase | Select Phrase,Influence | Export-CSV "C:\MyFolder\CFPhrases.txt"

To import the phrases on another Edge Transport server, use the Add-ContentFilterPhrase cmdlet:

Import-Csv "C:\MyFolder\CFPhrases.txt" | foreach {Add-ContentFilterPhrase -Phrase $_.phrase -Influence $_.influence}

User Self-Service: Message Tracking from OWA

One of the things on top of my Exchange wish lists, and I'm sure on the Exchange wish lists of many Exchange folks, is allowing users to help themselves with common tasks such as managing Distribution Groups, and tracking the status of their own messages as I suggested in Message Tracking as part of OWA/Outlook (hard to believe this was posted in July 2005!).

Yes, Exchange has had Message Tracking for administrators, but this results in the waste of valuable IT resources when users call/e-mail/shoutout (depending on location and position... ) why a particular message they were supposed to receive hasn't yet made it, or why someone never received a message they sent.

Exchange 2010 allows users to track their own messages using the Exchange Control Panel (ECP). Head over to Spotlight on Exchange 2010: Delivery Reports on the Exchange team blog for more info.

I'll gladly admit the final implementation of this feature is a lot better than the way I thought it should work 4 years ago. Allowing users to perform common tasks using easy-to-use web-based self-service options, using functionality found out-of-the-box in Exchange Server, should help you reduce administration costs and resources.

What's your take on these self-service features?

Using Outlook's Instant Search on Windows Server 2008

If you have Microsoft Outlook 2007 installed on Windows Server 2008 (perhaps because you're also using a lab server as your workstation, or require Outlook for testing), when you start Outlook it complains about Windows Search service not being installed and that Outlook cannot provide fast search results when using the Instant Search feature.


Figure 1: Microsoft Outlook 2007 prompt indicating Windows Search service is not installed

Outlook also displays a clickable notification under the Instant Search box.


Figure 2: Microsoft Outlook 2007 notification to enable Instant Search

Clicking on the notification brings up the same dialog box shown in Figure 1.

In Online mode, Outlook 2007 uses Exchange Search for searching the mailbox - the mailbox is not cached locally.

In Cached Mode, it uses Windows Search service to index messages in the cached copy of your mailbox. Windows Vista includes Windows Desktop Search (WDS) out-of-the-box. Windows Server 2008 and Windows XP do not.

Of course, you can disable the prompt to enable Instant Search in Outlook by going to Tools | Options | Other tab | Advanced Options, and unchecking Show prompts to enable Instant Search. But if you live in a high-volume email environment and have a fairly large mailbox to show for it, Search is an invaluable tool!


Figure 3: Disabling the prompt to enable Instant Search in Outlook 2007

Install Windows Search service
To install the Windows Search service on Windows Server 2008, use the following command:

ServerManagerCmd -i FS-Search-Service

Or install it using the Server Manager console using the following procedure:

1. Start Server Manager
   
2. Click Roles in the navigation tree on the left
   
3. Select Add Role in the Roles Summary section
   
4. Select the File Services role and click next
   
5. Select the Windows Search role service
   

After Windows Search is installed, when you click the notification in Outlook, it acknowledges Windows Desktop Search has been installed, and prompts you to restart Outlook to enable Instant Search.

Meanwhile, Windows Search indexes your email and documents in the background. If you use Instant Search before indexing is complete, it returns results from the messages it has already indexed, and notifies you of number of items still to be indexed.

Windows Search 4.0 is the more current version of Windows Search. Download: x64 | x86 .

ASN1 Bad Tag Error Installing an SSL Certificate in IIS 7

You've installed SSL certificates on previous versions of IIS more times than you care to remember. It's no rocket science - you create a certificate request, request the certificate from a Certification Authority, get the certificate and complete your certificate request.

Then there's IIS 7. Modularized. Optimized. Secure. You follow the same procedure as you did with previous versions of IIS. Create a certificate request, check. Get the certificate from a CA, check. Install the certificate, and that's where the familiarity ends. Instead of installing the certificate, IIS 7 throws up a cryptic error: There was an error while performing this operation. Details: CertEnroll::CX509Encrollment::p_InstallResponse: ASN1 bad tag value met. 0x8009310b (ASN: 267).


Figure 1: IIS 7's cryptic error when trying to install an SSL certificate

If you fire up the Certificates console (start a new MMC console | add Certificates snap-in | select the computer account), you'll see the certificate is indeed installed.

By default, IIS does not create a binding for HTTPS.


Figure 2: IIS 7's default site bindings

Add a binding for HTTPS

1. In the Site Bindings window, click Add
   
2. In the Add Site Binding window, select https from the Type: drop-down.
   
3. Select an IP address (or optionally, leave All Unassigned selected if you want the site to bind to the specified SSL port on all IP addresses
   
4. From the SSL certificate: drop-down, select the certificate you want to use for the binding/web site.
   
   [Optional] You can click the View button to view the certificate and ensure you're selecting the right one.
   
   Figure 3: Creating a binding for https in IIS 7
   
5. Click OK to close the Add Site Binding window.

Close the Site Bindings, start a browser, and test the web site using https.

Exchange Server Remote Connectivity Analyzer: Test Exchange from outside the firewall

Exchange 2007 brought with it a number of Exchange shell cmdlets that let you test Exchange functionality (scroll down to the end of this post for a list of the test cmdlets). But how do you test Exchange services are actually available and usable from the Internet?

Have you longed for an Exchange cmdlet like Test-ExchangeConnectivity which could test your Exchange services such as Outlook Anywhere, AutoDiscover, Exchange ActiveSync, and SMTP from outside your firewall?



Now there is! Exchange Remote Connectivity Analyzer is a web-based service that lets you test Exchange functionality and availability from the Internet. Best of all— it's free!

Exchange Remote Connectivity Analyzer answers your Exchange operations questions, such as:

1. Can my Exchange server receive inbound Internet/SMTP email?
   
2. Can my Outlook Anywhere (aka "RPC over HTTP" in Exchange 2003) clients connect from outside the firewall?
   
3. Can my mobile users connect using Exchange ActiveSync phones/devices?
   
4. Does AutoDiscover work for Outlook 2007 clients?
   
5. Does AutoDiscover work for Exchange ActiveSync clients?
   
6. Are the certificates used for these services valid?

Head over to Exchange Remote Connectivity Analyzer at testexchangeconnectivity.com. More details, and a great video, in Announcing the release of Exchange Server Remote Connectivity Analyzer on the Exchange team blog.

Exchange 2007's Built-In Test Cmdlets
Here's a list of Exchange 2007 Test Cmdlets. Although these test cmdlets aren't intended to replace full-fledged monitoring software or diagnostics systems, they do allow you to test a lot of Exchange functionality quickly and easily, without having to fire up a console or browser!

1. Test-ActiveSyncConnectivity: Lets you test ActiveSync synchronization
   
2. Test-EdgeSynchronization: Test EdgeSync status of subscribed Edge Transport servers, including whether a specified recipient is synchronized
   
3. Test-ExchangeSearch: Test Exchange Search status/health for a specified server or individual mailbox.
   
4. Test-ImapConnectivity: Test IMAP functionality on a Client Access Server
   
5. Test-IPAllowListProvider: Test if an IP address is listed in an IP Allow List Provider (a DNS-based list, think of it as the opposite of an IP Block List Provider or RBL)
   
6. Test-IPBlockListProvider: Test whether an IP address is listed in an IP Block List Provider (aka RBL)
   
7. Test-Mailflow: Test mailflow, including mail submission, transport, and delivery, from the System Mailbox on an Exchange Server to another Exchange Server or specified email address
   
8. Test-MAPIConnectivity: Test MAPI connectivity to an Exchange server or a specified mailbox. A MAPI logon is performed. This test will also create a mailbox in the MDB for those freshly created/enabled mailboxes that haven't been logged on to.
   
9. Test-OutlookWebServices: Test AutoDiscover configuration for Outlook 2007.
   
10. Test-OwaConnectivity: Test connectivity to Outlook Web Access, including certificate validation.
    
11. Test-PopConnectivity: Test POP3 connectivity for a specified Client Access Server
    
12. Test-ReplicationHealth: Test the health of Continuous Replication
    
13. Test-SenderId: Test SenderID status for a specified IP Address (the sending host) and domain.
    
14. Test-ServiceHealth: Test the status of services set to start automatically.
    
15. Test-SystemHealth:
    
16. Test-WebServicesConnectivity:

Internet Explorer 8 and OWA: Where Are The Images?

Internet Explorer 8 was released last week at MIX09. It's likely many users may already be running either the RTM version or one of the earlier betas.

IE 8 is more secure than previous versions (see Stay Safer Online for a list of IE8's security features), including some of the default settings. Here's one of those changes and how it may impact your OWA users (and potentially result in a helpdesk call).

A user gets an HTML message with images. When viewing the message in OWA, the user sees missing images, as shown below:


Figure 1: An HTML message rendered in OWA with missing images

Instead of this:


Figure 2: HTML message with images rendered in OWA

Is that the web beacon and form filtering feature of OWA 2007 at work?

OWA 2007: Web beacon and form filtering

Web beacons (aka "web bugs") are very small, transparent image files in web pages and HTML email. These 'invisible' images are commonly used by web sites to track visitors, along with cookies. When you inadvertently download such an image in an HTML email message, it calls home and tells Mr. Spammer: "I made it! The email address is valid, and someone even viewed the message!"

In Exchange 2007, OWA blocks web beacons, and displays the following prompt inline in the information bar (where header information such as subject, sender, recipient, and timestamp are displayed).


Figure 3: The web beacon and form filtering feature displays a prompt in the information bar to allow user to unblock content

If users determine the message is from a trusted sender and safe to open, they can unblock the blocked content by clicking on the "Click here" link in the information bar (highlighted in Figure 3 above).

Web beacon and HTML form filtering behavior can be controlled for an OWA virtual directory. Use the Set-OwaVirtualDirectory cmdlet to toggle the FilterWebBeaconsAndHtmlForms property, as shown in How to Control Web Beacon and HTML Form Filtering for Outlook Web Access.

But you don't see the familiar click here link in the message!

The Tale of The Two Prompts
You're accessing OWA (or any other web page for that matter) over a secure HTTPS session. The page has images or other unsecure content (not unsecure as in malicious content, but the content is accessed using HTTP) it wants the browser to display. The first time the browser faces this scenario, it sends alarm bells ringing. It warns you, the user almighty, and asks you what you wish to do.

You may even remember the IE prompt— even if vaguely so. Yes, the one you dismissed by clicking the "Yes" button, without giving it any thought? Afterall, what harm could a lowly web page do to your highly secure computer?

In IE8, the prompt has been reworded, and the choices reordered. Here's what the shiny new prompt looks like.


Figure 4: Security warning in Internet Explorer 8, clearly informing users about blocked content, and the potential security impact of displaying such content

As you can see, users instinctively clicking the "Yes" button continue to be protected by Internet Explorer 8. They do not end up in an insecure state! Moreover, the dialog is clearer and more informative, compared to the one found in previous versions of IE. Here's the dialog from IE 7:


Figure 5: The 'Security Information' prompt in Internet Explorer 7, prompting users about nonsecure items

Released: PowerShell Snap-in For IIS 7

The big news from MIX09 is probably the release of Internet Explorer 8, but for shell aficionados, Exchange folks and scripting geeks, the release of IIS Snap-in for Windows PowerShell is not a lesser event. The snap-in has 71 cmdlets to manage IIS, from web application pools to web site configurations, bindings, and SSL.

Download the IIS Snap-in for Windows PowerShell: X86 | x64.

For more information about the snap-in, head to IIS.net. IIS developer Sergei Antonov, who owns scripting and command-line tools, blogs here.

Curious to find out which cmdlets are included? Head over to the IIS 7 Cmdlets mini-reference.

Released: Exchange 2007 SP1 Update Roll-up 7

Update Roll-up 7 for Exchange Server 2007 SP1 has been released. Download it here.

As noted in previous posts, Exchange 2007 updates are cumulative and release-specific. This roll-up is for Exchange 2007 SP1, and supersedes all previous update roll-ups for Exchange 2007 SP1.

As Ananth notes in the post on the Exchange team blog (read 'Update Roll-up 7 for Exchange Server 2007 Service Pack 1 has been released'), this update has 50 fixes, including important fixes for SCR and IMAP4 issues.

Fixes for the following issues are included (details in KB 960384):

• 946449 A non-read report message is sent after you perform a "Mark All as Read" operation against unread e-mail messages in Exchange Server 2007
  
• 949113 Unexpected modified instances of a recurring meeting may appear when you use Entourage to access a calendar on a computer that is running Exchange Server 2007
  
• 949114 Duplicate calendar items may appear when you use Entourage to access a calendar on an Exchange 2007 server
  
• 949464 The customized properties are removed in the recipients' calendars when you send a meeting request that includes customized properties
  
• 950115 When a CDO 1.2.1-based application generates a meeting request that includes some European characters in the message body, these characters appear as question marks in Exchange 2007
  
• 951341 Users cannot read calendar items when they connect Exchange Server 2007 by using certain IMAP4 or POP3 clients
  
• 952778 Event ID 9874 is frequently logged on Exchange Server 2007 with Service Pack 1
  
• 953094 The value in the "Messages queued for submission" performance counter on the mailbox role of Exchange Server 2007 increases after a meeting request is delivered
  
• 954213 All Test commands that are related to the Client Access Server fail when you run the commands on an Exchange 2007 server in a disjoint namespace
  
• 954741 The UseRUSServer parameter does not work if an administrator has specified an RUS server on a target mailbox server
  
• 954898 The LegacyExchangeDN attributes for mail-enabled objects are incorrectly set in an environment that contains Exchange 2003 and Exchange 2007
  
• 955027 The Edgetransport.exe process may crash on a hub transport server that is running Exchange Server 2007 Service Pack 1
  
• 955462 You notice high CPU usage when the IMAP service is running on an Exchange 2007 Service Pack 1 server that has the CAS role
  
• 955778 You receive a Non-Delivery Report (NDR) message when you send an e-mail message to a non-SMTP address in an Outlook client that is using Cached mode
  
• 956069 A Non-Delivery Report (NDR) is generated when an Exchange Server 2007 user tries to send a message to a recipient who has a one-off FAX address that includes any characters that are larger than 0xFF in Unicode
  
• 956205 Corrupted characters appear in the Subject field or in the Location field of a recurring calendar item after a user adds DBCS characters to a field in a meeting occurrence by using an Outlook 2002 client
  
• 956275 An Exchange 2007 sender's address is split into two separate addresses when an external recipient replies to the message
  
• 956455 The display name appears in a received message even though the property of the user mailbox is set to "Hide from Exchange address lists" in Exchange Server 2007
  
• 956687 Messages stay in the submission queue after you enable per-mailbox database journaling in an Exchange Server 2003 and Exchange Server 2007 coexisting environment
  
• 957019 Images cannot be pasted in an Exchange Server 2007 Outlook Web Access message body
  
• 957071 The MSExchange Transport service may crash intermittently on the Exchange 2007 server
  
• 957124 You do not receive an NDR message even though your meeting request cannot be sent successfully to a recipient
  
• 957227 The Exchange Management Console crashes when one or more domain controllers of a top-level domain are not reachable
  
• 957485 The Test-OwaConnectivity command returns a warning message in Exchange Server 2007 when there is a disjoint namespace
• 957504 The IMAP4 service crashes intermittently, and Event ID 4999 is logged on Exchange Server 2007
  
• 957683 An IP Gateway can still be used to dial out for a "Play on Phone" request after the IP Gateway is disabled
  
• 957834 Network shares are deleted and created intermittently by the replication service on an Exchange SCC cluster when SCR is enabled on the Exchange server
  
• 957947 The Exchange Information Store service may crash when an Entourage client synchronizes with an Exchange 2007 server
  
• 958091 You cannot update the task complete percentage to any value other than 0 or 100 in Outlook Web Access
  
• 958093 Voice mail messages are not stamped with the disclaimer that is defined in the transport rule in an Exchange Server 2007 environment
  
• 958128 Replication messages stay in a queue in a retry state after a public folder database is dismounted
  
• 958331 The Restore-StorageGroupCopy command may fail in an Exchange Server 2007 SCR environment
  
• 958444 Event 522 is logged when replication is resumed on a suspended Storage Group on an Exchange Server 2007 CCR or SCR environment
  
• 958472 An unexpected text string appears at the top of the message body when an Exchange Server 2007 user sends an HTML message by using Outlook Web Access
  
• 958552 The ByteEncoderTypeFor7BitCharsets setting does not take effect for the US ASCII character set after you install the hotfix that is mentioned in Microsoft Knowledge Base article 946641
  
• 958638 Exchange 2007 Server cannot parse X-Priority headers from clients that submit X-Priority headers that contain additional comments
  
• 958803 The EdgeTransport.exe process may stop responding in Exchange Server 2007 when the priority queuing feature is enabled
  
• 958872 The Map This Address feature in the contact page for an OWA client does not work in Exchange Server 2007
  
• 959100 Exchange Server 2007 cannot route e-mail messages to mail enabled Non-MAPI public folders that are hosted on an Exchange Server 2003 server
  
• 959135 Event 9673 occurs when the Microsoft Exchange Information Store service crashes on a computer that is running Exchange 2007 with Service Pack 1
  
• 959397 An increase in database size is generated unexpectedly when IMAP4 users use a Copy command in Exchange 2007
  
• 959434 The last logon time is not updated to reflect the logon times that have occurred after users log on to their mailboxes by using the Entourage client in an Exchange 2007 environment
  
• 959545 A redirection message in Outlook Web Access 2007 is incorrect when the message is translated to Korean
  
• 959671 The Manage Mobile Devices option is not displayed in Exchange Management Console after a mobile device re-synchronizes with an Exchange 2007 server
  
• 959952 The Set-Mailbox command does not change the AutomateProcessing attribute for an Exchange Server 2007 user when a regular user mailbox is converted from a room mailbox
  
• 960291 Outlook Web Access or an Exchange Web Service application does not correctly display a monthly or yearly recurring appointment or meeting request
  
• 960292 The MSExchangeIMAP4 service may crash intermittently after you apply an update rollup for Exchange Server 2007 Service Pack 1
  
• 960349 The Exchange Information Store service may crash after you enable tracing for the logon actions
  
• 961281 An error is returned when you enable SCR from any source in a child domain after you install Exchange Server 2007 Service Pack 1 Rollup 5
  
• 961395 The Exchange 2007 Unified Messaging server does not update the caller information if an external user makes a call
  

Are Distribution Groups really being used?

Over the years, you end up creating a large number of Distribution Groups based on user demands. The regular departmental Distribution Groups such as Sales, Marketing, Engineering, and HR. The geographical ones such as AllUS, All-California, All-BayArea, and so on. The ones by employment status such as All-FTE for full-time employees, All-Contractors, and so on. And ones to facilitate the working habits of executives and senior managers, who want to address their team with a distro (geekspeak for Distribution Group) like JoeSchmoe-DirectReports. Then there are the more interesting ones, such as All-MountainClimbers, All-GrungeFans.

Why are so many of these Distribution Groups prefixed with an All-? Can Distribution Groups ever be All-Whatever? Is it possible to include all grunge fans in the All-GrungeFans group? Or only the ones who confess? Can you guarantee everyone in the Sales dept will be included in the All-Sales group by default— even if you used Dynamic Distribution Groups? There will be times when someone does not populate the department attribute for the newly hired Manager of Inside Sales for Timbuktu, and surrounding areas. After two weeks in his exciting new inside sales position, the poor bloke finds out he hasn't received the number of sales leads freely flying around on the distro, and unfortunately won't be able to meet his targets for selling surfboards in Timbuktu that quarter.

Over the lifetime of Exchange deployments, there will be groups that get used more frequently, such as Send-Your-Jokes-Here-If-You-Have-Nothing-Better-To-Do-At-Work (the alias conveniently shortened to ExecTalk... ), or the ones that never get used, such as All-ExEmployees (hard as it is to believe, at least one of these two have been spotted in real-world deployments!).

One fine day, your friendly manager/auditor/HR person shows up at your desk wanting to know which distribution groups are in use.

That's where message tracking logs come to the rescue— assuming these are enabled. If you've been mucking around with these logs in Exchange 2007, you probably know a fair bit of PowerShell, and chances are you're absolutely loving it! If not, head over to previous post Exchange Server 2007: Message Tracking from the command line, and get to know the wonderful cmdlet Get-MessageTrackingLog.

Tracking messages sent to Distribution Groups
How do we get a list of messages sent to Distribution Groups? By getting a list of all Distribution Group expansion events, noted in message tracking logs with the EventID EXPAND. The RelatedRecipientAddress field in the EXPAND entry contains the PrimarySmtpAddress of the Distribution Group expanded. Use the following command to grab a list. You can restrain Get-MessageTrackingLog cmdlet in a number of ways. Since these have been covered in the previous post, I won't go into details here.

Get-MessageTrackingLog -Start 2/1/2009 -EventID Expand | ft Timestamp,RelatedRecipientAddress -Autosize

You get back a table that looks something like this:

Timestamp RelatedRecipientAddress
--------- -----------------------
2/18/2009 4:36:27 PM DG-Marketing@MyDomain.com
2/18/2009 4:41:18 PM DG-Sales@MyDomain.com

Next, how do we determine how many messages each Distribution Group received? This is easily done by piping the results to the Group-Object cmdlet:

Get-MessageTrackingLog -Start 2/1/2009 -EventId Expand | group-object RelatedRecipientAddress | ft Name,Count -Autosize

This returns a count for each group of messages:

Name Count
---- -----
DG-Marketing@MyDomain.com 123
DeptSales@MyDomain.com 145

To list messages sent to a particular Distribution Group:

Get-MessageTrackingLog -EventID Expand | ? {$_.RelatedRecipientAddress -like "DG-Marketing@MyDomain.com"} | ft Timestamp,Sender,MessageSubject -Autosize

Of course, you could use the message tracking GUI in EMC— but would it rate anywhere close on your geek satisfaction index?

Applying Exchange 2007 SP1 Update Rollup 6

Perhaps I should have picked another day for applying Exchange 2007 SP1 Update Rollup 6. I ran into the services not starting issue documented in KB 944752 Exchange Server 2007 managed code services do not start after you install an update rollup for Exchange Server 2007.

It was a single server topology - Exchange 2007 SP1 sitting behind ISA Server 2006 (SP2), with no previous post-SP1 rollups installed. The System Attendant, Information Store, and Active Directory Topology services started without any issues. The other Exchange services did not. Manually starting the stopped services resulted in the familiar 1053 error - service failed to start in a timely fashion.


Figure 1: Manually starting Exchange managed services resulted in error 1053

A helpful colleague informed me about the nature of these managed services, and pointed me to the above KBA and the related downloads. Installing .Net Framework 2.0 SP2 fixed it, although according to the KBA .Net Framework 2.0 SP1 would work just as well.

The managed code services not starting issue is mentioned clearly in KBA 959241 Description of Update Rollup 6 for Microsoft Exchange Server 2007 Service Pack 1:

Note Certain Exchange Server 2007 managed code services may not start after you install this update rollup. This problem occurs if all the following conditions are true:

• The services cannot access the following Microsoft Web site:
  http://crl.microsoft.com/pki/crl/products/CodeSigPCA.crl
  
• You do not have a .NET Framework common language runtime (CLR) build that supports the generatePublisherEvidence configuration setting.

For more information about how to resolve or work around this issue, click the following article number to view the article in the Microsoft Knowledge Base:
944752 Exchange 2007 managed code services do not start after you install an update rollup for Exchange 2007

Rudimentary best practices
When working in mid to large deployments, we normally tend to follow change control procedures in place. Service packs, hotfixes, and updates are tested adequately. Change control also translates into being able to articulate a suitable fallback plan. Backups need to be performed before applying any updates. These practices, even in a scaled down version, are routinely ignored or avoided in smaller environments.

Installing updates without testing and without reading the accompanying documentation could turn into your little adventure on days you can ill-afford to indulge in such adventures. The consequences could range from hours wasted (read "unbillable hours" if you're a consultant) troubleshooting or restoring service, to potentially more serious consequences caused by the downtime.

The good news is this can be avoided easily!

Have you been in a situation before where not following these rudimentary best practices has resulted in undesirable consequences?

Released: Update Rollup 6 for Exchange 2007 Service Pack 1

Update Rollup 6 for Exchange Server 2007 SP1 has been released. Download it here.

As noted in previous posts, Exchange 2007 updates are cumulative and release-specific. Additionally, as Ananth notes in the post on the Exchange team blog (read 'Update Rollup 6 for Exchange Server 2007 Service Pack 1 Released'), this update has a fix for a security issue rated as critical, and the update to allow Internet Explorer 8 to be used to access Outlook Web Access does not include the S/MIME control. An updated version of the control will be released in a future rollup.

Fixes for the following issues are included (details in KB 959421):

• 959239 MS09-003: Vulnerabilities in Microsoft Exchange could allow remote code execution
  
• 950675 Downloaded .xls file attachments are empty when you open the files by using Outlook Web Access on Exchange Server 2007 Service Pack 1
  
• 955443 Some free/busy messages are not replicated from Exchange 2007 to Exchange 2003 servers after some mailboxes are migrated from Exchange Server 2003 to Exchange Server 2007
  
• 956356 The Microsoft Exchange File Distribution service uses lots of memory and processor time when Exchange Server 2007 processes many OABs
  
• 956624 The Microsoft Exchange Transport service crashes continuously after you enable journal rule or deploy an antivirus application on an Exchange Server 2007 server
  
• 957748 The custom message class of contact object is overwritten by the normal IPM.Contact class when an Exchange 2007 server replicates the contact object to any other public store

Managed Folders: Why aren't Calendar items expired?

You're testing Exchange 2007's Messaging Records Management (MRM) features to implement your organization's messaging retention policies.

You create a new Managed Folder for Calendar items, and then create a Managed Content Setting for it to expire Calendar items in 1 year. Next, you create a Managed Folder Mailbox Policy and add the Managed Folder to the Policy. You apply the policy to a test mailbox.

Testing the Managed Folder Policy
You open the test mailbox, create a single-instance appointment that starts and ends on some date more than a year ago.

To test the new Managed Folder Policy, you manually run the Managed Folder Assistant against your test mailbox:

Start-ManagedFolderAssistant -Mailbox "Joe Adams"

You expect the meeting, which (starts and) ends at some date more than a year ago, to be expired and the RetentionAction specified in the Managed Content Setting to be applied. It doesn't.

Calculating Retention Age for Calendar items

You can tell the MFA when to start counting an item's retention age from, by specifying it in the Content Settings for a Managed Folder. It can be based on:
1) When the item was delivered to a mailbox or
2) When the item was moved to a folder


Figure 1: Configuring retention period in Managed Content Settings

Calendar items such as meetings and appointments, and Tasks, are treated differently since these items have an end date. You could create a meeting for a future event, or create a recurring meeting that takes place at a certain interval (daily/weekly/monthly/yearly) during a certain period, or indefinitely. Therefore, the end date of these items needs to be considered when expiring them. Recurring meetings will expire based on the end date of the last occurrence. Meetings with no end date do not expire.


Figure 2: Recurring meetings can be scheduled to occur daily, weekly, monthly, or yearly for a long period, or indefinitely. When expiring such items, the MFA considers the end date.

If these items are deleted, and thus end up in the Deleted Items folder, the end date is no longer a factor. The Managed Folder Assistant expires Calendar items in the Deleted Items folder based on the message-received date. If the received-date cannot be determined, the message-creation date is used.

More details about retention age for different types of items in "How Retention Periods Are Calculated for Items in Managed Folders".

You locate an older PST and copy a Calendar item which occurs in roughly the same timeframe as the one you just created. When you run the MFA, the copied item with an end date from more than a year ago is expired!

When processing a mailbox, the MFA queries for Calendar items where the creation date is older than the expiration date. If you create a test item for a past date, as we did in this case, it does not get processed by the MFA until the creation date is older than the AgeLimitForRetention.


Figure 3: Calendar items created for a past date will have a creation time that is later than the meeting/appointment end time

Of course, you're not likely to run into this issue except in test scenarios. Real-world meetings do not get created in the past. The creation date is guaranteed to be equal to or older than the end date of the meeting..

EHLO: DSNConversionMode and You

If you haven't already read Jason Nelson's take on Delivery Service Notifications (DSNs), head over right away to DSNConversionMode and You: An Administrator's Guide.

Returning all recipients from the Forest in recipient cmdlets

If you're trying to get recipients from the whole AD Forest using the Exchange shell, there are two things to be aware of:

1. Session scope: By default, the scope of your shell session is set to the Domain of the computer you're running the session on.
2. Result size: By default, shell cmdlets return 1000 results. You can modify this using the Resultsize parameter. The number of search results to return can be specified, or you can use the value unlimited to return all results.

To view the current settings for your admin session, simply type $AdminSessionADSettings.

What you get back:

ViewEntireForest : False
DefaultScope : MyDomain.com
PreferredGlobalCatalog :
ConfigurationDomainController : MyDC.MyDomain.com
PreferredDomainControllers : {}

You can change the DefaultScope parameter to specify another domain or an OU. (Recipient cmdlets also have the OrganizationalUnit parameter which lets you restrict the command to a particular OU).

To return recipients from the whole Forest for all recipient cmdlets used in the session, you can set the session scope by using the following command:

$AdminSessionADSettings.ViewEntireForest = $True

Note, session variables are limited to the session. Once you close the shell window, it's gone. If you start another session, you'll need to set the ViewEntireForest variable to $True again.

You may find not having to return recipients from the entire Forest for the most part. If you do not want to change your session scope to the Forest, but return all recipients in a single recipient command, you can bypass the session scope by adding the IgnoreDefaultScope switch with recipient cmdlets:

Get-Mailbox -IgnoreDefaultScope -ResultSize unlimited

Other parameters such as the preferred GC, DC and config DC for the session can also be set by modifying the session variable.

SCRIPT: List Delegates With Send On Behalf Access

Send On Behalf access allows a user to send mail on behalf of the mailbox owner.


Figure 1: Send On Behalf access can be assigned from ADUC | recipient properties | Exchange General | Delivery Options, or by the mailbox owner using Microsoft Outlook

Here's a script that lists all users with delegates.

File: listDelegates.zip

Related posts and links:

• Understanding Exchange Server 2003 Mailbox Access Delegation
  
• List users with email forwarding enabled
  
• HOW TO: Export all email addresses from a domain
  
• SCRIPT: Show mailbox limits
  
• SCRIPT: Reset Mailbox Limits
  

Released: Update Rollup 5 for Exchange 2007 SP1

Update Rollup 5 for Exchange Server 2007 SP1 has been released. Download it here.

As noted in previous posts, Exchange 2007 updates are cumulative and release-specific.

Fixes for the following issues are included (details in KB 953467):

• 925371 Domino Server does not see attachments in meeting requests from Exchange Server 2007
  
• 939037 By default, managed content settings apply to the root folder and all subfolders in an Exchange Server 2007 environment
  
• 949722 An Event 800 event message does not log the username of users who ran the Get-MessageTrackingLog command in an Exchange 2007 environment
  
• 949893 You cannot create a new mailbox or enable a mailbox in an Exchange Server 2007 environment on February 29, 2008
  
• 949895 Exchange Management Shell crashes (stops responding), and Event ID 1000 is logged when you perform a cross-forest migration from Exchange Server 2003 to Exchange Server 2007 S949895
  
• 949901 Exchange 2007 users cannot send e-mail messages to a mail-enabled public folder in a mixed Exchange 2003 and Exchange 2007 environment
  
• 949968 Unified Messaging does not handle the diversion header correctly in Exchange Server 2007 Service Pack 1
  
• 950272 The formatting of a plain text message is incorrect when you print the plain text message by using Outlook Web Access in an Exchange Server 2007 environment
  
• 951267 An exception occurs in Exchange Management Console when you preview AddressList in an Exchange Server 2007 environment
  
• 951273 The received date and the received time of IMAP messages are changed to the time of migration after you migrate mailboxes to an Exchange 2007 Service Pack 1-based server
  
• 951505 You may receive an error message when you run the Update-SafeList cmdlet in an Exchange 2003 and Exchange 2007 mixed environment
  
• 951564 Exchange 2007 S951564 Update Rollup 5 supports the addition of new items to context menus in Outlook Web Access 2007
  
• 951710 You receive error messages or warnings when you change an Active Directory schema so that the Company property supports more than 64 characters
  
• 952097 Update Rollup 5 for Exchange 2007 Service Pack 1 introduces events 12003 which can be used to clarify ambiguous Event messages
  
• 952583 Japanese DBCS characters are corrupt when you reply to a message or forward a message in an Exchange Server 2007 S952583 environment
  
• 953619 A public folder conflict message cannot be delivered, and event error 1016 is logged, when the public folder name contains DBCS characters in an Exchange Server 2007 Service Pack 1 environment
  
• 953787 You receive an error message when you try to move Exchange 2000 mailboxes or Exchange 2003 mailboxes from one forest to an Exchange 2007 server that is located in another forest by using the Move-Mailbox command
  
• 953840 Event ID 5000 occurs, and the IMAP4 service may crash, on a server that is running Exchange Server 2007 with Service Pack 1 when you use a third-party application to migrate POP3 and IMAP4 users
  
• 954036 Hidden folders or files are listed when you view a UNC file server by using OWA in an Exchange 2007 environment
  
• 954195 The task originator is not notified of task changes and task progress in an Exchange Server 2007 environment
  
• 954197 Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters
  
• 954270 Message class changes during conversion when a digitally signed Message Disposition Notification is received by a server that is running Exchange Server 2007 Service Pack 1
  
• 954451 An appointment item cannot be opened by a CDOEX-based application if the item is saved by Exchange Web Service together with the Culture property in Exchange Server 2007
  
• 954684 You cannot use an Outlook 2007 client to display or download an attachment when you access a message that includes an inline attachment from Exchange Server 2007
  
• 954810 An Exchange 2007 room mailbox stops processing requests after the resource booking assistant receives a delegated meeting request from an Exchange 2003 user
  
• 954887 You cannot add a Mail User or a Mail Contact to the Safe Senders list in Microsoft Exchange Server 2007 by using OWA client
  
• 955001 Error message when you use the IMAP protocol to send a SEARCH command that has the CHARSET argument on an Exchange 2007 server: "BAD Command Argument Error"
  
• 955196 Log files are not copied to the target server in a standby continuous replication environment in Exchange Server 2007
  
• 955429 VSS backup application causes the Information Store service to crash repeatedly on an Exchange 2007 Service Pack 1-based server
  
• 955460 The start time and the end time of a meeting request are incorrect when a delegate uses Exchange Web Service to send the request in an Exchange 2007 environment
  
• 955480 Meeting requests from external senders are displayed as Busy instead of Tentative in an Exchange Server 2007 environment
  
• 955599 Event ID 10 messages fill up the Application log on an Exchange 2007 CAS server if an Exchange Server 2003 mailbox owner makes an Exchange Web Service call
  
• 955619 A user cannot access the mailbox by using a POP client or an IMAP client through Client Access Server in an Exchange Server 2007 environmen
  
• 955741 A message stays in the Outbox, and the message is resent until it is deleted manually on Windows Mobile 6.1-based devices in an Exchange 2007 Service Pack 1 CAS proxying scenario
  
• 955946 If a private message is submitted by a SMTP sender, the sender receives an NDR message from the Exchange 2007 server
  
• 955989 The SPN registration of a cluster fails, and Error event IDs 1119 and 1034 are logged in an Exchange Server 2007 Service Pack 1 environment
  
• 956199 The last character of a user’s Chinese display name is truncated in the Offline Address Book on an Exchange 2007 server
  
• 956319 The W3wp.exe process may crash on an Exchange 2007 CAS server after you use Entourage to send a message that is larger than 48 KB
  
• 956573 Event ID 1032 is not logged in the Application log when users send e-mail messages while they are logged in to Outlook Web Access as another user in Exchange Server 2007
  
• 956582 Exchange Server 2007 Update Rollup 3 does not update the Outlook Web Access Logon.aspx file after you modify the file
  
• 956613 The W3wp.exe process intermittently stops responding and Event ID 1000 is logged in Exchange Server 2007 Service Pack 1
  
• 956709 Some recurring meetings may be missing when you view the meetings using Outlook Web Access in Exchange Server 2007
  
• 957002 The Edgetransport.exe process may crash intermittently on a server that is running Exchange Server 2007 Service Pack 1
  
• 957137 The reseed process is unsuccessful on the CCR passive node after you restore one full backup and two or more differential backups to the CCR active node
  
• 957813 A Non-Delivery Report is generated when you try to send a high priority message that is larger than 250 KB in an Exchange Server 2007 Service Pack 1 environment
  
• 957978 The OAB generation is unsuccessful and Event IDs 9328 and 9373 are logged in the Application log in a Windows Server 2008-based Exchange 2007 Single-Copy cluster environment
  
• 958855 The Edge Transport service crashes repeatedly, and an event error 1000 is logged repeatedly on a server that is running Exchange Server 2007 Service Pack 1
  
• 958856 Event ID: 7012 occurs when you search message tracking logs on an Exchange Server 2007-based server
  

Start Managed Folder Assistant for a single mailbox

When testing Managed Folder Mailbox Policy settings in Exchange 2007, you may need to frequently run the Managed Folder Assistant (MFA)) to process a mailbox on-demand, so you can check the mailbox content and MRM logs. However, every time you run Start-ManagedFolderAssistant, the MFA processes all mailboxes on all Mailbox Databases on the server.

Of course, you can avoid all the agony by instructing the Managed Folder Assistant to process only the specified mailbox:

Start-ManagedFolderAssistant -Mailbox "Foo"

Processing a single mailbox results in the MFA completing its job quickly and makes parsing the MRM log easier— the MFA only logs events related to the specified mailbox.

The -Mailbox parameter does not take multiple mailboxes as input. To process more than 1 mailbox, you will need to use the Get-Mailbox cmdlet (or Get-User piped to Get-Mailbox, depending on the property you want to filter on) and pipe a filtered list of mailboxes to Start-ManagedFolderAssistant. For example, the following command will result in the MFA processing all mailboxes from the department:

Get-User -Filter {department -eq "Sales" -and RecipientType -eq "UserMailbox"} | Get-Mailbox | Start-ManagedFolderAssistant

Or maybe you want to have the MFA process all mailboxes with a particular policy applied. Note, the Filter requires the distinguishedName of the policy:

$policy = (Get-ManagedFolderMailboxPolicy "MRMPolicy-VPs").distinguishedName; Get-Mailbox -Filter {ManagedFolderMailboxPolicy -eq $policy} | Start-ManagedFolderAssistant

Update Rollup 4: The Right Thing To Do

Now that Exchange 2007 SP1 Update Rollup 4 has shipped, it's time to revisit recent events preceding it.

A few days before yesterday's release, a pre-release version of Update Rollup 4 for Exchange Server 2007 SP1 made its way to Microsoft Update. Customers who had the Automatic Updates feature of Windows Server OS configured to automatically download and install updates got the pre-release version downloaded and applied automatically to those servers. Although it was detected and removed quickly from Microsoft Update, the update has left some customers affected by this issue quite annoyed— and understandably so.

Microsoft's Scott Roberts posted the details on the Exchange team blog in INFO: Update Rollup 4 for Exchange Server 2007 Service Pack 1, including some of the issues faced by customers, and workarounds. Scott also responded to customers who left comments on the blog post, and frequently updated the post/comments.

Although this has proved to be a major annoyance for some customers, overall the number of customers affected was relatively quite low.

What's of note is the upfront communication about this through the Exchange team blog. Rather than trying to sweep the issue under the carpet, it was actually talked about! Fessing up about such issues, apologizing where apologies are due, and ensuring adequate controls are in place so such things do not happen again is the right thing to do.

It's also a sign of how Microsoft is increasingly being more open about such incidents.

Computerworld's Gregg Keizer wrote about this in Microsoft issues wrong update for Exchange 2007. Surprisingly, other tech media outlets such as News.com and InfoWorld did not pick this up.

Keizer notes:

"For a brief period of time on 9/9, a pre-release version of Update Rollup 4 for Exchange Server 2007 Service Pack 1 was inadvertently made available to Microsoft Update, the Microsoft Update Catalog and WSUS servers for download," an unidentified Microsoft employee said in a post to the official Exchange blog.

To set the record straight, the linked post is written by Scott Roberts, and clearly attributed to him with a link to his bio.

Auto-updating Servers and Server Apps?

Given the incident, it's easy to respond with "We can't trust Microsoft to automatically push patches that work!" — and you can't be blamed for thinking that way. In fact, you shouldn't trust any vendor to automatically push patches and updates to servers and server apps. In many organizations, patches for desktop/laptop OS and apps are also accorded similar treatment.

Although most software vendors test patches— some more extensively than others, there are a staggering number of variations in configurations, topologies, software and hardware deployed by customers. It is close to impossible to test a patch and account for these variations, and chances of a patch being tested for an environment exactly like yours are arguably quite slim.

It is a Patch Management best practice (and has been for as long as I can remember) to not auto-apply patches to servers and server applications without first testing these in a lab environment. A test and change control process— however rudimentary it may be, always helps in orderly deployment of patches, tracking of such updates, and forces you to think of a back-up plan.

It's a good idea to always apply a patch or update on a test box or two, then roll it out to production servers— starting with low-impact/low-priority servers first to discover problems early on. This ensures that should things go wrong, the initial impact is low. As the patch or update is applied to more servers and you move to more critical/high-impact servers, you've gradually reduced the chances of things going wrong. (Of course, the exact method of rolling out and the order in which servers get a patch applied will vary in each organization and may depend on the type of patch being applied.)

Small businesses, some with no full-time IT staff, many with a single server, may not be able to justify the cost of a test environment or a consultant to test patches and updates.

One option is to use virtualization software such as Microsoft's hypervisor-based Hyper-V (the standalone Hyper-V Server 2008, or the Virtualization/Hyper-V role of Windows Server 2008), the non-hypervisor-based Microsoft Virtual Server 2005 R2, or Microsoft VirtualPC 2007 for desktops— (all of them except Windows Server 2008 are free), to setup a virtual test environment.

If you are a consultant responsible for supporting many such small businesses, perhaps you can test patches on behalf of customers, and distribute the cost to a number of customers. You can generate additional revenue, and customers can get the assurance that the patches they deploy are tested by someone responsible for maintaining their servers— someone who knows their environment well. It can reduce the possibility of downtime, and is generally cheaper than actual downtime of critical services or applications.

Having patches and updates automatically applied to servers, without any testing, can and will land you in trouble at some point— regardless of the vendor.

Released: Update Rollup 4 for Exchange 2007 SP1

Update Rollup 4 for Exchange Server 2007 SP1 has been released. Download it here.

Fixes for the following issues are included (details in KB 952580):

• 942649 Description of the commands that support the UseRusServer option that is imported in Update Rollup 4 for Exchange Server 2007 Service Pack 1
  
• 944831 You cannot configure Exchange Server 2007 so that the simple display name appears in outgoing messages
  
• 945854 A meeting reminder is still active when you configure Outlook to send no reminders to an Exchange Server 2007 user
  
• 945870 TAB symbols may be converted incorrectly to spaces in Exchange Server 2007
  
• 948896 Certificates that contain wildcard characters may not work correctly on an Exchange 2007-based server
  
• 948897 An attachment incorrectly appears as the body of the e-mail message in an Exchange Server 2007 environment
  
• 948923 Users do not receive information in DSN messages in Exchange Server 2007 with Service Pack 1
  
• 949512 An embedded message is removed from the attachment list on Exchange Server 2007 if the embedded message subject ends with .com, .exe, or any other blocked extension
  
• 949782 An In-Policy request that is forwarded to delegate appears as an Out-Of-Policy request if a user submits an In-Policy meeting request against a room mailbox of Exchange 2007 server
  
• 949858 The provisioning process cannot be successful when you use Microsoft Identity Lifecycle Manager (ILM) 2007 to provision user objects for Exchange Server 2007
  
• 949926 Error when you use an IMAP4 client or a POP3 client to log on to a delegate mailbox of Exchange Server 2007: "800cccd1"
  
• 950076 After you move a mailbox from Exchange Server 2003 to Exchange Server 2007 Service Pack 1, you cannot edit rules in Outlook Web Access
  
• 950081 Error message when users use an SMTP client to send e-mail messages in Exchange Server 2007 Service Pack 1: "454 4.7.0 Temporary authentication failure"
  
• 950138 You are prompted for your credentials three times and you receive an error message when you use the Outlook Anywhere feature to connect to an Exchange Server 2007 Service Pack 1–based server that is running Windows Server 2008
  
• 950198 You can enable AfterConversion snapshot for all messages if pipeline tracing and Content Conversion Tracing are enabled
  
• 950235 The IMAP4 or POP3 worker process may stop responding on an Exchange 2007 CAS role that is working with an Exchange 2003 back-end server
  
• 950409 The reminder is triggered earlier than expected when an Exchange Server 2007 server receives an iCalendar meeting request message over an SMTP server
  
• 950622 Messages are converted to a very small font size in Outlook Web Access and in Outlook 2003 when you use Exchange Server 2007
  
• 950976 Event ID 115 may be logged intermittently on a computer that is running Exchange Server 2007 with Service Pack 1
  
• 951067 Event ID 7034 may be logged in the Application log in Exchange Server 2007 when an MAPI application tries to access a mailbox in a certain way
  
• 951156 The message body of some appointments appears garbled after you use a mobile device that is running Traditional Chinese edition Windows Mobile 6 to synchronize appointments that was created in Outlook Web Access for Exchange Server 2007
  
• 951251 A MAPI application does not work correctly if Exchange 2007 is installed on a Windows Server 2008 server
  
• 951594 The W3svc log reports the incorrect number of attachments on an Exchange Server 2007 server that has deployed Exchange ActiveSync Service (EAS)
  
• 951747 An error occurs when you use the Export-mailbox or Restore-mailbox command to migrate certain mailboxes on Exchange Server 2007: "error code -1056749164"
  
• 951864 Some users must enter their credentials when they access rights-protected messages even though you have deployed the Rights Management Services (RMS) prelicensing agent on an Exchange Server 2007 Service Pack 1-based server
  
• 952152 The Autodiscover service for ActiveSync in an Exchange 2007 environment does not work for users in sites that do not have the ExternalURL property set
  
• 952250 You encounter a long delay for each mailbox when you run the "Move-Mailbox" or "Set-Mailbox" command on an Exchange Server 2007 computer
  
• 952682 Log file drives on the SCR target may eventually fill up and cause replication failure in Exchange Server 2007 Service Pack 1
  
• 952924 Error message when Exchange users try to access public folders that are hosted on Exchange Server 2003 by using Outlook Web Access for Exchange Server 2007: "Outlook Web Access is unable to open public folders"
  
• 953312 The "Open Message In Conflict" button is not available in the conflict notification message for Exchange Server 2007 users
  
• 954058 You can change the method for transfer encoding after you apply Update Rollup 5 for Exchange Server 2007 Service Pack 1
  
• 954205 Event ID 1113 is logged in the Application log on a Unified Messaging (UM) server when users contact the UM server by using secured connections
  
• 954237 The IMAP service crashes intermittently on Exchange 2007, and Event ID 5000 is logged
  
• 955208 Event ID 5000 occurs when the Exchange IMAP4 worker process crashes intermittently in Exchange Server 2007
  
• 956775 CopyItem and MoveItem Operations in Exchange Web Services can return the Item ID after you install Update Rollup 4 for Exchange Server 2007 Service Pack 1
  
• 957133 Description of improvements in functionality that occur in Exchange Web Services operations after you install Update Rollup 4 for Exchange Server 2007 Service Pack 1

Disable Antispam agents on a Receive Connector

Exchange 2007's antispam agents are enabled for all Receive Connectors on a transport server. Is there a way to disable the agents on a particular Receive Connector?

Although not as simple as turning an agent off for each IP address or Receive Connector, Exchange 2007's new transport permissions model allows you to do this just as easily.

The ms-Exch-Bypass-Anti-Spam permission is what allows a sender to bypass antispam agents. By default, mail from authenticated senders is not filtered.

To allow unauthenticated/anonymous senders to bypass antispam filters on a particular Receive Connector, use the following command:

Get-ReceiveConnector "My Receive Connector" | Add-ADPermission -User "NT Authority\Anonymous Logon" -AccessRights ExtendedRight -ExtendedRights ms-exch-bypass-anti-spam

Related Posts and Links:

• Removing internal host names and IP addresses from message headers
  
• Why Get-TransportAgent doesn't agree with the Exchange console
  
• Exchange 2007 Content Filter: How to move messages to Junk Mail folder
  
• Exchange 2007 Content FIlter: The Whitelist Is Here!
  
• Exchange 2007 Transport Permissions Model
  

Resource Mailbox Calendar Settings: Configuring resource mailboxes using OWA

Have you been using the Set-MailboxCalendarSettings cmdlet to configure scheduling settings for resource mailboxes? Wish there was a graphical interface to configure these settings?

[PS] C:\>get-mailboxcalendarsettings cf-oahu | fl

AutomateProcessing : AutoAccept
AllowConflicts : False
BookingWindowInDays : 180
MaximumDurationInMinutes : 1440
AllowRecurringMeetings : True
EnforceSchedulingHorizon : True
ScheduleOnlyDuringWorkHours : False
ConflictPercentageAllowed : 0
MaximumConflictInstances : 0
ForwardRequestsToDelegates : True
DeleteAttachments : True
DeleteComments : True
RemovePrivateProperty : True
DeleteSubject : True
DisableReminders : True
AddOrganizerToSubject : True
DeleteNonCalendarItems : True
TentativePendingApproval : True
EnableResponseDetails : True
OrganizerInfo : True
ResourceDelegates : {}
RequestOutOfPolicy :
AllRequestOutOfPolicy : False
BookInPolicy :
AllBookInPolicy : True
RequestInPolicy :
AllRequestInPolicy : False
AddAdditionalResponse : False
AdditionalResponse :
RemoveOldMeetingMessages : True
AddNewRequestsTentatively : True
ProcessExternalMeetingMessages : False
DefaultReminderTime : 15
RemoveForwardedMeetingNotifications : False
Identity : MDomain.com/Conference Rooms/CF-Oahu

Output of Get-MailboxCalendarSettings cmdlet

Christian Schindler, MCT, MCA (Messaging), from Austria points out the little known fact that you can use OWA to configure calendar settings for resource mailboxes. Note, the user accounts for resource mailboxes are disabled by default. You would need to enable the account in ADUC before you try to logon using OWA.

An alternative to enabling resource mailboxes

If you want to avoid enabling resource mailbox accounts, here's an alternative. You can assign yourself (or any other account) FullAccess permission on the resource mailbox(es) you want to configure. Use the following command:

Get-Mailbox -Filter {RecipientTypeDetails -eq "RoomMailbox"} | Add-MailboxPermission -User "YourAccount" -AccessRights FullAccess

With the permission assigned, you can log on to OWA using your account, and open the resource mailboxes using OWA 2007's ability to open additional mailboxes, as shown in the following screenshot.

If you look at Options in OWA when logged in as an ordinary mailbox user (that is, not logged on to a resource mailbox), you see Calendar Options.

If you log on to a resource mailbox using OWA, you also see Resource Settings as one of the options.


Figure 1: The Resource Settings option is available in OWA when logged on to a resource mailbox. Full size screenshot here.

Not only does this allow you to configure the settings for automated processing of meeting requests, there's also a rich text editor for creating a custom response message.


Figure 2: The Resource Settings option also has a rich text editor for creating a custom HTML response message.

Related posts and links:

• HOW TO: Convert a user mailbox to a resource mailbox
  
• Cmdlet help: Set-MailboxCalendarSettings
  
• Managing Resource Scheduling
  
• How to Enable or Disable Automatic Booking on a Resource Mailbox
  
• How to Enable Explicit Logons in Outlook Web Access

Configuring Deleted Item Retention

After a user empties the Deleted Items folder, although these items disappear from the view of the mailbox, they are not completely deleted. They are retained till the Deleted Item Retention period expires in what's fondly referred to as the Dumpster— not to be confused with the Transport Dumpster maintained by Hub Transport servers.

Deleted Item Retention (DIR) can be configured on the Mailbox Database. It is set to 14 days by default. The other related parameters that can be configured on the MDB include deleted mailbox retention period and the option to not purge deleted items until the MDB has been backed up.


Figure 1: Deleted Item Retention settings for a Mailbox Database


Configuring Deleted Item Retention per-mailbox
Individual mailboxes can be configured with a different Deleted Item Retention period, which bypasses the limit set on the Mailbox Database. To configure the individual DIR settings for a mailbox using the Exchange console:
1. In Recipient Configuration | Mailbox | select recipient --> Properties | Mailbox Settings tab | double-click Storage Quotas

2. In the Storage Quotas property page, uncheck Use mailbox database defaults


3. In the Keep deleted items for days field, enter a new value

4. Optional: Check Do not permanently delete items until you back up the database

Why is it a good idea to not purge the dumpster till the Store has been backed up?
If not checked, items in the Dumpster will expire after the Deleted Items Retention period, and be permanently lost! If the Dumpster is purged before a backup takes place, the item is lost forever, with no way to recover it. Retention Policies in many organizations require that all messages or mailbox items should be recoverable.

5. Click OK to close the Storage Quotas property page | click OK to close mailbox properties.

Modifying the Deleted Item Retention period for a mailbox using the Exchange shell
The DIR period can be set by populating the RetainDeletedItemsFor property using the Set-Mailbox cmdlet. Using the shell's ability to pipe objects (output from one cmdlet to be processed by another cmdlet), you can use Get-Mailbox with the -Filter property and get the desired set of mailboxes to apply the new DIR period in bulk. You can also use a number of other properties to filter mailboxes based on the OU, Mailbox Database, Storage Group, etc. For example:

Get-Mailbox -OrganizationUnit "San Francisco" | Set-Mailbox -RetainDeletedItemsFor 20.00:00:00

(See Applying Managed Folder Policy to more than one user for more examples. The list of filterable properties that can be used in the -Filter parameter: Exchange 2007 RTM | SP1).

However, simply setting the RetainDeletedItemsFor property does not apply the new retention period to mailboxes. Remember the checkbox in the console for Use mailbox database defaults? How do we uncheck that using the shell?

Let's get all *Deleted* properties of a mailbox:

Get-Mailbox "My Mailbox" | ft *Deleted* -AutoSize

What you get back is:


The value modified by the checkbox in the console shows up in the DeletedItemFlags column in the Get-Mailbox output. It can have three values:
1) DatabaseDefault when the checkbox is selected
2) RetainForCustomPeriod when it's not
3) RetainUntilBackupOrCustomPeriod— a third value, if you've also selected the option not to purge the Dumpster before the Store's backed up.

At this point, I wouldn't blame you if you instinctively proceed to use the Set-Mailbox cmdlet to flip the DeletedItemFlags property from DatabaseDefault to RetainForCustomPeriod. However, this doesn't work.

What Get-Mailbox actually displays as the DeletedItemFlags is a calculated property— properties which are calculated and displayed for ease of administration, but aren't actual properties that can be modified using the corresponding Set-Whatever cmdlet.

The property we need to modify is called UseDatabaseRetentionDefaults. It's a boolean property— valid values can be $true or $false.

When setting a custom/non-default Deleted Item Retention period on mailboxes, we should set the UseDatabaseRetentionDefaults property to $false:

Set-Mailbox "My Mailbox" -RetainDeletedItemsFor 20.00:00:00 -UseDatabaseRetentionDefaults $false

The Get-Mailbox output after this is done:


If you also set RetainDeletedItemsUntilBackup to $true:


Getting Dumpster Statistics
To get the total number and size of deleted items in the dumpster for a mailbox, use the Get-MailboxStatistics cmdlet:

Get-MailboxStatistics User@MyDomain.com | Select *Deleted*

The output:

DeletedItemCount TotalDeletedItemSize
---------------- --------------------
752                16020237B

Doesn't the output from the above command include the Deleted Items folder?
No. To get the statistics for the Deleted Items folder, use:

Get-MailboxFolderStatistics User@MyDomain.com | where {$_.FolderPath -like "/Deleted Items"}

The output:

Date : 9/16/2008 7:15:49 PM
Name : Deleted Items
Identity : User@MyDomain.com\Deleted Items
FolderPath : /Deleted Items
FolderId : LgAAAAAaFeUR2TeSRpY38Ihx7YFNAQCK6B+B4tC8RbU9t9FmHnW4AAAAABIcAAAB
FolderType : DeletedItems
ItemsInFolder : 361
FolderSize : 6214440B
ItemsInFolderAndSubfolders : 361
FolderAndSubfolderSize : 6214440B
OldestItemReceivedDate :
NewestItemReceivedDate :
ManagedFolder : DI30days

Related posts and links:

• Configuring Deleted Mailbox and Deleted Item Retention
  
• How to Configure Deleted Item Retention for a Mailbox Database
  
• How to Configure Deleted Item Retention for a User
  
• How to Recover a Deleted Item

Unraveled: The Mystery of the Disappearing Exchange Update Rollup 4

Did you really see Exchange 2007 Update Rollup 4 appear and then quickly disappear earlier this week?

Scott Roberts explains in 'The case of disappearing Rollup Update 4' on the team blog.

SCRIPT: Get Storage Group Backup Status

Exchange 2007 Mailbox Databases expose backup-related properties using the Get-MailboxDatabase cmdlet:

Get-MailboxDatabase "My Database" -status | select *backup* | fl

What you get back:
BackupInProgress :
SnapshotLastFullBackup :
SnapshotLastIncrementalBackup :
SnapshotLastDifferentialBackup :
SnapshotLastCopyBackup :
LastFullBackup :
LastIncrementalBackup :
LastDifferentialBackup :
LastCopyBackup :

Here's a quick shell script that dumps each Storage Group and its backup-related information. I haven't had the time to build in any validation or test to run remotely, but you can use it on an Exchange 2007 server to get the following details:

1. Storage Group Name
2. Transaction log file path
3. Date Storage Group was created
4. Name and timestamp of the oldest transaction log file
5. Number of transaction log files in the path
6. Mailbox Databases in each Storage Group
7. For each MDB, time when full, incremental, and differential backups (Streaming or VSS) were performed
(including a warning if the first log file is still available, which basically means a Full backup has never been completed).

In the following screenshot, the First Storage Group has never been backed up, so the E**00000001.log file still exists (and its timestamp is same as the Storage Group's creation time). The second Storage Group has just been backed up, and therefore has fewer transaction logs.


Figure 1: Output of Get-SGBackupStatus.ps1 script

File: Get-SGBackupStatus.zip
Date: 9/11/2008

What needs to be added:
- Time (number of days/hours) from last backup
- Warning when last backup is older than X number of days

Using the -Status switch: Reader Wolfgang Sauer points out

If you saw this post yesterday and wondered why the *backup* fields in Get-MailboxDatabase output were showing up as blank (or $null in PowerShell-speak), even after a backup has been taken, it's because we left out the -Status switch that's required with Get-MailboxDatabase cmdlet to make these details show up. Thanks to reader Wolfgang Sauer from Germany for pointing out the omission.

The script and the screenshot have been updated accordingly. If you downloaded the script before today, please download the updated version.

Disclaimer:
All scripts/downloads on this site provided as-is, with no warranties, and confer no rights. Please test any scripts/downloads in a lab environment before using it in production.

Troubleshooting Exchange Performance: Performance Analysis of Logs (PAL) tool

Interested in monitoring and troubleshooting Exchange Server performance? Check out the Performance Analysis of Logs (PAL) tool on CodePlex.

PAL creates some great reports that provide a better analysis of Exchange performance data than actually looking at perfmon counters all day. Mike Lagase has more details in his blog post "Performance Troubleshooting using the PAL tool".

Related posts:

• Monitoring Exchange Server 2007 Performance: Perfmon counters and thresholds
  
• Fixed: Outlook 2007 Performance issues with large mailboxes
  
• Perfmon counters show up as numbers?
  
• Troubleshooting IMF: Important performance counter
  

HOW TO: Prevent annoying spam from your own domain

One of the more annoying types of spam is the one that seems to be coming from your own domain; or worse— from your own email address! Of course, users from your own domain don't generally spam each other— unless you're using one of the free web-based email services. And most of us don't spam ourselves.

Obviously, this is coming from a spammer who has spoofed your email address, or that of someone else from your domain. Unfortunately, SMTP— the protocol that allows mail clients and servers to exchange email, allows headers to be spoofed easily.

In Exchange Server 2007, Accepted Domains tell Exchange which domains to accept email for. If a domain - e12labs.com in this example, exists as an Accepted Domain, there is no reason external senders should use that domain in the MAIL or FROM headers.

You may have remote POP3/IMAP4 users who use SMTP to send mail. However, such sessions should be authenticated, and preferably use a separate Receive Connector.

Thanks to the extensive Transport Permissions model in Exchange 2007, we can easily prevent such spam. Receive Connectors have the ms-exch-smtp-accept-authoritative-domain-sender permission which dictates whether an Accepted Domain can be used in the MAIL or FROM headers. External/internet hosts submit mail to your server without authentication, as anonymous senders. To prevent anonymous senders from sending mail using your domain(s), we need to remove the ms-exch-smtp-accept-authoritative-domain-sender permission assigned to them.

Use the following command to remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon on internet-facing Receive Connector(s):

Get-ReceiveConnector "My Internet ReceiveConnector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

Once this permission is removed, when anonymous senders try to submit mail using your Accepted Domain(s), here's how the SMTP conversation goes:

220 E12Postcard.e12labs.com Microsoft ESMTP MAIL Service ready at Wed, 3 Sep 2008 06:22:43 -0700
helo
250 E12Postcard.e12labs.com Hello [172.31.0.170]
mail from:jadams@e12labs.com
550 5.7.1 Client does not have permissions to send as this sender

Exchange stopped spoofing of P1/envelope headers. Let's continue the session and try to spoof the P2 headers (the ones in the DATA part of the message) — maybe that'll work!

mail from:someone@someotherdomain.com
250 2.1.0 Sender OK
rcpt to:jadams@e12labs.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
from:jadams@e12labs.com
subject: Header spoofing

This is how we spoof headers, spoof headers.

.
550 5.7.1 Client does not have permissions to send as this sender
quit
221 2.0.0 Service closing transmission channel

As you can see, removing the ms-exch-smtp-accept-authoritative-domain-sender permission stops spoofing of your domains in both envelope (P1) and message (P2) headers.

When not to remove the permission?
Is there a scenario where one should not remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon? Yes, on Receive Connectors used by internal or trusted SMTP hosts (such as copiers/scanners and application servers) that submit mail without authentication.

But you do have these internal/trusted hosts submitting to a separate Receive Connector, don't you?

Related posts:

• Exchange Server 2007: How To Allow Relaying
  
• Removing internal host names and IP addresses from message headers
  
• Header Firewall: Why spammers can't insert fake SCL (and other Exchange Organization) X headers
  

Announced: Virtualization support for Exchange Server 2007

Exchange Server 2007 is now supported on Hyper-V and other (read "Non-Microsoft") hypervisors validated under the Microsoft Server Vitualization Validation Program. Vendors participating in the program: Citrix, Cisco Systems, Novell, Sun Micrososystems, and Virtual Iron Software.

The new support policy for Exchange in virtualized environments: Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments.

• What's supported: Exchange Server 2007 SP1 running on Windows Server 2008
  
• Supported Exchange 2007 Server Roles: All except Unified Messaging
  
• What Hypervisor: Microsoft Hyper-V, or any hypervisor validated by MSVVP
  
• Not supported: Differencing disks and expandable virtual disks
  
• Not supported: Taking VM snapshots (these aren't application-aware)
  
• Not supported: Combining Exchange's clustering features (SCC and CCR) with availability features from the virtualization layer, such as Hyper-V's quick migration.

A change has also been made to licensing policies allowing transfer of licenses for server applications (such as Exchange and SQL Server) between servers as frequently as required. This was earlier restricted to 90 days. This facilitates virtualization, where VMs running these server applications can be easily transferred from one server to another. More about the change in licensing policy in the Volume Licensing Brief titled Application Server License Mobility (Word DOC).

More details about the announcement in the Exchange team blog post: Microsoft Virtualization and Licensing Announcements

Exchange System Manager and Outlook on the same computer?

With the release of Exchange System Manager (ESM) for Windows Vista yesterday (Released: Exchange System Manager for Windows Vista), there's been concern about the fact that ESM is not supported on the same computer as Microsoft Outlook. However, the coexistence of the two has not been a supported scenario for long.

From KB 266418: Microsoft does not support installing Exchange Server components and Outlook on the same computer:

Microsoft does not support installing Microsoft Outlook and Microsoft Exchange Server 2003 (including Exchange System Manager), Microsoft Exchange 2000 Server (including Exchange System Manager), or Microsoft Exchange Server 5.5 on the same computer. The Product Support group does not support the coexistence of Outlook and Exchange on the same computer in a production environment.

The KBA provides an explanation of the issue related to MAPI32.DLL, and also indicates that these can be installed on the same computer for demonstration purposes. They're not supported in production.

Comments on the Exchange team blog post yesterday indicate many folks (myself included in the past) have been doing exactly that... installing ESM and Microsoft Outlook on the same computer. It's not the same thing as installing Outlook on the Exchange Server, something I haven't attempted in a long time, and wouldn't encourage you to do.

William Lefkovics (Exchange MVP and fellow coauthor of Exchange Server 2007: The Complete Reference) has a great overview about this on Slipstick: A Mixed History of Remotely Managing Exchange Servers

Released: Exchange System Manager for Windows Vista

If you've been waiting to install Exchange System Manager on Windows Vista, the wait is finally over.

Exchange System Manager for Windows Vista is now available.

Pre-requisites:
- The computer should be a member of a domain which has Exchange Server 2003 SP2.
- Windows Server adminpak (from Windows Server 2003 SP1 or Windows Server 2003 R2)

Known Issues (from the Release Notes):

• SMTP Current Sessions node is not supported (SMTPadmin.dll cannot be registered)
  
• NNTP property view is not supported (NNTPadmin.dll cannot be registered)
  
• Installing ESM on a computer which has Microsoft Outlook installed is not supported
  

Exchange Server Antispam Updates: Do I have the latest update?

Not sure if the Exchange 2007 or 2003 (IMF) updates on your system are the latest and greatest? Doubt if the automatic update process is working?

You can use the Microsoft Update Catalog web site to search for these. You can also subscribe to the RSS feeds for each update (search result on the web site).

• Exchange Server 2007 Antispam updates  
  
• Exchange 2003 Intelligent Message Filter updates  
  

You can also use the site to search for other Microsoft products and subscribe to the feeds.

Delay Notifications: Informing users about delays in mail delivery

Users consider email to be a reliable communication mechanism - not as reliable as the dial tone, but pretty close. Most users expect mail to be delivered within minutes, if not seconds.

Many organizations, including those operating in the financial & banking sectors, have strict SLAs for mail delivery which specify mail delivery times granularly— for mail within a particular location (that is, within a Routing Group in Exchange 2003 and within an AD Site in Exchange 2007), between two locations, and to/from the internet.

Exchange Server sends a delay notification to inform the sender if delivery of a message is delayed beyond a configured timeout. The default delay notification timeout in Exchange Server 2003 is 12 hours. This has been reduced to a (comparatively) more realistic 4 hours in Exchange Server 2007.

When considering changing these defaults, it's a good idea to consider any SLAs and user expectations. Is it reasonable to expect a user to wait for 24 hours before informing him/her about a delay? 12 hours? 1 hour?


Figure 1: In Exchange 2007, the default delay notification timeout is 4 hours

You can change the delay notification timeout using the Exchange console (EMC) from Server Configuration | Hub Transport | SERVERNAME -> Properties | Limits tab.

To change delay notification timeout using the Exchange shell:

Set-TransportServer "SERVERNAME" -DelayNotificationTimeout 01:00:00

This sets the notification timeout to 1 hour. The value is specified in dd.hh:mm:ss (the standard format used by the shell). Valid values— minimum: 00:00:01 (yes, 1 second!) to 30.00:00:00 (30 days). It's recommended to wait till transient failure retries have been completed before sending a delay notification (that is, higher than TransientFailureRetryInterval x TransientFailureRetryCount).

In Exchange Server 2003, the delay notification timeout can be changed from SMTP Virtual Server | Properties | Delivery tab. There are different delay notification timeouts for outbound and local mail.

If you decide users don't need to know about mail delivery delays (and there could be perfectly legitimate reasons for that - although as I write this I can't think of any... ), you can disable delay notifications:

Set-TransportServer "SERVERNAME" -ExternalDelayDsnEnabled $false -InternalDelayDsnEnabled
$false

Have you changed the default delay notification in your organization? What is a reasonable time for notifying users about delays?

Related:

• SMTP Virtual Servers: Some irksome defaults you should change
  
• Set-TransportServer
  

PowerShell: Listing multi-valued attributes

In previous posts, we've taken a look at how to update multi-valued attributes and remove values from multi-valued attributes using PowerShell/Exchange Shell (EMS).

Multi-valued attributes have a special significance in AD, and interfaces/APIs used to access AD. Whereas single-valued attributes can be retrieved and updated quite easily, multi-valued attributes come with a twist. Values from a multi-valued attribute are returned as an array (of values). To evaluate values in a multi-valued attribute, you need to iterate through each one (using a foreach loop in most cases). Similarly, when updating a multi-valued attribute, we need to remember we're adding/updating one value of what could possibly be multiple items in an array.

With that out of the way, a real-word experience relates to how these values are listed in Exchange shell cmdlet output. For instance, the BypassedSenders property of ContentFilterConfig may have a few dozen safe senders that you do not want to subject to the Content Filter. If you list these bypassed senders using Get-ContentFilterConfig, the output will list a few bypassed senders. Note the trailing dots to indicate there are more values?

Using a format-list or fl (Get-ContentFilterConfig |select BypassedSenders | fl) doesn't help.


Figure 1: Output from Exchange shell cmdlets does not list all values in multi-valued attributes

BypassedSenders and Safelist Aggregation

The Content Filter Agent does not filter messages from addresses on its BypassedSenders property, regardless of the recipient. This should not be confused with a recipient's Safe Senders list (used by the Safelist Aggregation feature) to bypass mail for a recipient from the senders he/she adds to Safe Senders list in Microsoft Outlook. CFA's BypassedSenders is global in scope.

To get a list of all values in a multi-valued attribute such as BypassedSenders:

$senders = (Get-ContentFilterConfig).BypassedSenders; $senders

Alternatively, you can list them without adding them to a hash table ($senders in above example):

(Get-ContentFilterConfig).BypassedSenders

Figure 2: Listing all values in BypassedSenders multi-valued attribute

Similarly, multiple IP addresses or address ranges in a Receive Connector's RemoteIPRanges property:

(Get-ReceiveConnector "MyConnector").RemoteIPRanges

or formatted as a table with the required info:

(Get-ReceiveConnector "MyConnector").RemoteIPRanges | ft Lowerbound,Upperbound,RangeFormat -AutoSize

Figure 3: Listing all values in RemoteIPRanges multi-valued attribute of a Receive Connector

Related posts:

• HOW TO Update multi-valued attributes in PowerShell
  
• HOW TO: Remove values from multi-valued properties using Exchange shell
  

Where are mailbox last logon, client IP address, and other details in Exchange 2007?

In Exchange Server 2003/2000, expanding a Mailbox Database provides information about mailboxes in a database, last logon/logoff times and account(s) that logged on to mailboxes (see 'Displaying Client IP Address in Exchange System Manager' for details).


Figure 1: In Exchange 2003, the Logons node displays Store logon-related information. Click here to see a bigger screenshot.

In Exchange Server 2007, these details are not displayed in the EMC. The reasons are not hard to guess. These details are retrieved by querying the mailbox database. In Exchange 2003, these were displayed when you selected the mailbox database, resulting in a single mailbox database being queried. In Exchange 2007, mailboxes are displayed when you select Recipient Configuration -> Mailboxes, and depending on the selected scope/filter, the console displays mailboxes from the entire organization. Querying all mailbox databases on different servers in a distributed organization can become very slow, generate a lot of extra network traffic— terribly inefficient.

Instead, why not allow the administrator to query for these details when they're actually required? The shell provides you the flexibility to only get the fields you want, only for the mailboxes you want, making it much more efficient. If you manage smaller Exchange deployments and love your GUI management tools, you may not fall in love with the idea. (But that debate's already settled, and you're going to have to learn some bit of Exchange shell to be able to manage Exchange 2007 and later. The good news is, it's cooler, easy-to-use, well-documented by now, and comes with plenty of help!).

Logon Statistics
The Get-LogonStatistics cmdlet provides the following logon-related information.

AdapterSpeed :
ClientIPAddress :
ClientMode :
ClientName :
ClientVersion :
CodePage :
CurrentOpenAttachments :
CurrentOpenFolders :
CurrentOpenMessages :
FolderOperationCount :
FullMailboxDirectoryName :
FullUserDirectoryName :
HostAddress :
LastAccessTime :
Latency :
LocaleID :
LogonTime :
MACAddress :
MessagingOperationCount :
OtherOperationCount :
ProgressOperationCount :
RPCCallsSucceeded :
StreamOperationCount :
TableOperationCount :
TotalOperationCount :
TransferOperationCount :
UserName :
Windows2000Account :
ServerName :
StorageGroupName :
DatabaseName :
Identity :

The command can be constrained to a mailbox database (get-logonstatistics -Database "MyDatabase" | fl), a mailbox server (get-logonstatistics -Server "MyServer"), or a particular mailbox.

Mailbox information
In ESM, the Mailboxes node of a Mailbox Store displays mailbox-related information such as mailbox size, number of items, and last logon/logoff.


Figure 2: In Exchange 2003, the Mailboxes node displays mailbox-related information. Click here to see a bigger screenshot.

This information can be retrieved using the Get-MailboxStatistics cmdlet. It provides the following information related to a mailbox:

AssociatedItemCount :
DeletedItemCount :
DisconnectDate :
DisplayName :
ItemCount :
LastLoggedOnUserAccount :
LastLogoffTime :
LastLogonTime :
LegacyDN :
MailboxGuid :
ObjectClass :
StorageLimitStatus :
TotalDeletedItemSize :
TotalItemSize :
Database :
ServerName :
StorageGroupName :
DatabaseName :
Identity :

It can also be constrained to a -Database, -Server, or mailbox.

Now that we're dealing with the shell, besides these cmdlets' built-in filtering capabilities (Database, Server, or mailbox), you can use Powershell's where-object cmdlet to further filter the results based on the properties returned by each cmdlet. For example, to find out logon sessions from a particular IP address:

Get-LogonStatistics -Server "MyServer" | where {$_.ClientIPAddress -like "192.168.2.101"}

Script: Listing Distribution Groups a recipient is a member of

It's easy to get a list of all members of a Distribution Group. The Exchange shell (EMS) ships with the Get-DistributionGroupMember cmdlet that makes it a short one-liner (compared to 100s of lines of code in VBS).

However, how do we get all Distribution Groups a user, group, or contact is a member of? There's no equivalent cmdlet that can list a recipient's distribution group memberships using the shell. From the AD side, a recipient's memberOf attribute is a back-linked attribute, which I briefly talked about in memberOf Attribute can now be used in OPATH filters!. A group's membership is stored in the group's member attribute.

In the following command/script (what's the boundary between a command and a script?? when do a bunch of commands become a script?), we look at all distribution groups in AD, look at each member and determine if it matches the one we're looking for.

$contact = get-contact "foo@somedomain.com"; Get-DistributionGroup | foreach {$dg = $_ ; write-host "Looking at: "
$dg; Get-DistributionGroupMember $dg | foreach {if ($_.identity -like $contact.identity) {"Member of : " + $dg} }}

Clearly, this isn't very efficient!

Using the ADSI provider

The shell can also look at the AD objects natively using the ADSI provider. It's not as friendly or easy to use (as a native AD provider for Powershell would probably be), but it's a huge improvement over VBScript. There's no need to grab AD objects into ADO recordsets— that part is taken care of by Powershell.

Here's one way to do this using the ADSI provider:

$dn = "LDAP://" + (Get-Contact foo@somedomain.com).distinguishedName; $foo=[ADSI]$dn; $foo.memberOf | foreach {$dg = $_; get-distributiongroup $dg}

Here's a script with some changes and validation: Get-DGMembership.zip

What it does: Uses the ADSI provider to get list of all groups a recipient is a member of, determines if the group is a Distribution or Security group, outputs names of Distribution Groups.
Usage:

.\Get-DGMembership.ps1 Mailbox1@mydomain.com

.\Get-DGMembership.ps1 Mailbox1@mydomain.com Contact2@somedomain.com

What we can really use is a native AD provider that lends the same automation capabilities to AD management tasks that the Exchange shell and Powershell lend to Exchange and Windows management tasks.

IIS 7 Authentication: What happened to the IUSR_MachineName account?

In previous versions of IIS, the IUSR_MachineName account is created for anonymous authentication. This is an actual user account created on the server (a domain account can be used in domain environments), and like all user accounts— it has a SID, and an account password with the accompanying management costs and risks.

One of the resulting annoyances (for me): when you install IIS first and then change the computer name, the computer name and the MachineName in IUSR_MachineName account don't match.

IIS 7 gets rid of the IUSR_MachineName account in favor of a built-in IUSR account that's guaranteed to have the same SID on all computers. This ensures ACLs copied from one web server to another work, domain accounts are no longer required, and applications can be easily deployed across multiple web servers. The IIS_WPG group (for IIS Application Pool identities) is replaced by the built-in group IIS_IUSRS.

Note: The IUSR_MACHINENAME account isn't completely gone— it is used for anonymous authentication to FTP, and gets created if/when you install FTP.

More on the IIS team blog in 'Understanding the Built-In User and Group Accounts in IIS 7.0'

- Security identifiers
- Well-known security identifiers in Windows operating systems

Released: Update Rollup 3 for Exchange Server 2007 SP1

Update Rollup 3 for Exchange Server 2007 SP1 has been released. Download it here.

Fixes for the following issues are included (details in in KB 949870):

• 937436 Error message when an Exchange 2007-based user sends a meeting request to a resource that is located in a Lotus Domino resource reservation database: "Error autoprocessing message"
  
• 941770 How to disable the "Sent by Microsoft Exchange Server 2007" branding sentence in an Exchange Server 2007 DSN message
  
• 945453 You cannot log on to Outlook Web Access in an Exchange Server 2007 environment, and you receive an error message: "HTTP Error 403.4"
  
• 947573 It takes a long time for the Exchange Management Console to load in an Exchange Server 2007 organization that was deployed in a multiple-domain environment
  
• 949206 ( The e-mail address of a contact does not appear in the Outlook Address Book after you use Exchange Web Services to edit the contact in Exchange Server 2007 with Service Pack 1
  
• 949549 Error message when you import a .pst file by running the Import-Mailbox cmdlet in Exchange Server 2007: "Unable to make connection to the server"
  
• 949778 The icons that represent TIFF attachments may not be shown correctly if the e-mail message is viewed by using Outlook Web Access 2007 in an Exchange Server 2007 environment
  
• 950153 A storage group may not mount after you move the resources from the active node to the passive node while the backup is in progress in Exchange Server 2007
  
• 950674 Web services sends meeting request information that has an incorrect time if a delegate modifies an appointment in an Exchange Server 2007 environment
  
• 951263 The heading of the "State" column is translated incorrectly in the German version of the Exchange Management Console in Exchange Server 2007
  
• 951293 Error message when you enter logon credentials after an Outlook Web Access session times out in Exchange Server 2007: "Server Error in '/ExchWeb/bin' Application"
  
• 953539 The W3wp.exe process may intermittently stop responding, and event ID 1000 is logged in Exchange Server 2007 Service Pack 1
  
• 950120 You cannot control the behavior of attachments on mobile devices by using the ActiveSync policy in Exchange Server 2007 Service Pack 1
  
• 951094 You cannot run the New-X400AuthoritativeDomain cmdlet successfully in an Exchange Server 2007 environment if an X.400 address contains a space character
  
• 953747 MS08-039: Vulnerabilities in Outlook Web Access for Exchange Server could allow elevation of privilege
  
• 950930 You cannot resolve a sender name or a recipient name when the name belongs to an alternative domain tree in Exchange Server 2007
  
• 950758 OVA announces "Unrecognized caller" in an Exchange Server 2007 environment even though Outlook and Outlook Web Access correctly resolve the caller address
  
• 951563 External e-mail message senders receive an NDR when you select the Turkish language setting on a computer that is running Exchange Server 2007 Service Pack 1
  

Creating a Dynamic Distribution Group for all mailboxes on a Database

I posted about this in Adventures with OPATH: some annoyances if you're used to LDAP, shortly after Exchange Server 2007 RTMed (Yes, it has really been that long... ). Here's a quick recipe to create a Dynamic Distribution Group to include all mailboxes on a database.

$DB = (Get-MailboxDatabase "SERVER\Storage Group\Mailbox Database").distinguishedName

New-DynamicDistributionGroup MyGroup -RecipientFilter {Database -eq $DB} -RecipientContainer "DC=MyDomain,DC=com" -OrganizationalUnit "OU=Distribution Groups,DC=MyDomain,DC=com" -RequireSenderAuthenticationEnabled $false

The first step gets the distinguishedName of the mailbox database in a variable called $DB.

Parameters:
- OrganizationalUnit: Specifies the container/OU where the group will be created
- RecipientContainer: Specifies container to pick up recipients from. If not specified, this gets set to the same value as the OrganizationalUnit parameter (the OU/Container where the group is created), and the filter may not return the expected recipients (or worse— may not return any recipients at all... )
- RequireSenderAuthenticationEnabled: As discussed in 'New Distribution Groups do not receive internet email by default', new groups do not receive internet email (that is, email from unauthenticated/anonymous senders)) by default. If you want the group to receive internet email, set this to $false.

Controlling OOFs per domain and per mailbox

OOFs can be controlled per domain using Remote Domain settings. By default, setup creates the default Remote Domain for address space *. (As with Connector namespaces, * translates to all domains for which Exchange isn't authoritative/has an Accepted Domain for, and doesn't have an explicit Remote Domain for).


Figure 1: Remote Domains allow control of OOF messages to the internet or specific domains

The choices:
None: OOFs are disabled for the remote domain.
External: Allows only external OOFs to be sent to the remote domain. OOFs created using legacy Outlook clients and those sent by Exchange 2003/2000 servers will be not be allowed. If blocking OOFs to external domains in Exchange 2003/2000, this allows you to restrict legacy Outlook clients from sending OOFs, but allow Outlook 2007/Exchange 2007 users to send external OOFs.
ExternalLegacy: Allows external and legacy OOFs to be sent to the remote domain.
InternalLegacy: Allows internal and legacy OOFs to be sent to the remote domain.

Allowing Internal OOFs to Remote Domains

The InternalLegacy setting sends internal OOF messages to a Remote Domain. If verbiage or content of internal OOFs isn't something you want to share with the outside world, do not use this for Remote Domains.



The InternalLegacy option can be useful in distributed organizations with multiple address spaces and multiple email systems, or specific cases where you may want to share such information with a trusted organization.

Controlling OOFs per-mailbox

Besides the settings in Remote Domains, you can also control external OOFs per-mailbox. This is done using the Set-Mailbox cmdlet. The ExternalOofOptions parameter defaults to External. You can change it to InternalOnly to restrict a mailbox user from sending OOFs outside the organization:

Set-Mailbox foo@mydomain.com -ExternalOofOptions InternalOnly

Related:

• While you were out: Scheduling meetings and OOFs
  
• The hilarious lingo of Exchange folks
  
• Why is OOF an OOF and not an OOO?
  
• Legacy client and Out of Office (OOF) interoperability
  
• OOF integration with Exchange Server 2007 Unified Messaging (UM)

Monitoring Exchange Server 2007 Performance: Perfmon counters and thresholds

Monitoring mission-critical services such as email is a necessity in most organizations. Whereas monitoring software like Microsoft SCOM can use Exchange monitoring expertise and rules encoded in Management Packs, and many third-party monitoring solutions ship with some embedded knowledge, if you're setting up a monitoring system or creating a home-grown app to do so, you need to know what to monitor.

I was fortunate enough to (sort of) take a course on Exchange performance monitoring at my previous employer, and get a lot of input on the subject from some great minds in the business. The resulting fondness for performance monitoring and performance counters is probably understandable.

If you share my enthusiasm for performance monitoring, here's some documentation and guidance you may find very useful:

- Monitoring Common Counters
- Monitoring Mailbox Servers
- Monitoring Hub Transport Servers
- Monitoring Client Access Servers
- Monitoring Unified Messaging Servers with System Center Operations Manager

Released: New Whitepapers on Continuous Replication and Planning for Large Mailboxes

New whitepapers have been released today on TechNet.

Whitepaper: Continuous Replication Deep Dive
- written by Ross Smith IV and Scott Schnoll

This whitepaper discusses the different components of Continuous Replication— used by LCR, CCR and SCR, how replication works, backups and log file truncation, what happens during scheduled and unscheduled outages, and how Continuous Replication compares with other replication solutions.

The whitepaper is available here.

Whitepaper: Planning for Large Mailboxes with Exchange Server 2007
- written by Tom Di Nardo

This whitepaper discusses planning and operational issues faced when dealing with large mailboxes, including planning storage, long database backup and online/offline maintenance times.

The whitepaper is available here.

Exchange Quick Audit: mailboxes created in last 7 days

I remember writing plenty of scripts to report on different things such as user accounts created every week/month, user accounts modified, accounts disabled, etc. for SOX compliance. Some of those scripts used to be rather long, and in hindsight— involved a lot more lines of code than an administrator should have to write. Although I had a lot of fun (and still do... albeit with PowerShell), I would totally understand if you said you never wanted to hear about things like Wscript, VBScript, WSH, COM objects, ADSI, and WMI ever again.


Let's take a look at how the shell (EMS) makes it so easy.

In this example, we need to get a list of all accounts created in the last 7 days. When a user account is created, its whenCreated attribute gets stamped with the time of creation. Here's how it can be used:

Get-User -resultsize unlimited | where {$_.WhenCreated -gt (get-date).adddays(-7)} | ft Name,whenCreated -Autosize

Similarly, when an AD object is changed, it's whenChanged attribute gets stamped with the time the change was made. This makes it easy to determine which objects were changed in a given period, a useful tool for auditing/reporting as well as troubleshooting. In the following example, we determine if any Receive Connectors were changed in the last 7 days.

Get-ReceiveConnector | where {$_.whenChanged -gt (get-date).adddays(-7)}

Another frequently required and requested report— how do I get a list of mailboxes that haven't been accessed in the last X days. Let's use 100 days as the value here:

Get-MailboxStatistics -resultsize unlimited | where {$_.LastLogonTime -lt (get-date).AddDays(-100)} | ft displayName,lastlogontime,lastloggedonuseraccount,servername

Or mailboxes that have never been logged on to:

Get-MailboxStatistics -resultsize unlimited | where {$_.LastLogonTime -eq $null | ft displayName,lastlogontime,lastloggedonuseraccount,servername

Note, you can filter mailboxes by Database or ServerName to restrict the results to a more manageable size.

Next, let's list mailboxes disabled in the last 14 days:

Get-MailboxStatistics | Where {$_.DisconnectDate -gt (get-date).AddDays(-14)} | ft displayName,ServerName,DatabaseName,TotalItemSize -Autosize

Released: Transporter Suite v08.02.0053

An updated version of the Transporter Suite— a set of tools for interoperability and migration from Lotus Domino and generic POP/IMAP servers to Exchange Server 2007, has been released.

Download Transporter Suite v08.02.0053 from here.
Updated release notes are here.

If you're getting started on an interop or migration project, take a look at Resources for Interoperability and Migration from Lotus Domino.

Modifying Display Templates and additional attributes

Recently got a question about customizing the GAL and my previous post that talks about it: "HOW TO: Modify Display Template to make default email address appear in Address Book/GAL".

The new Details Template Editor in Exchange 2007 (in EMC | Tools) makes it much easier to modify templates and give your GAL the kind of look you want (short of adding that 5 Mb. purple bitmap file as a background and an extra-large company logo perhaps... :). Screenshots and more information about Details Templates can be found in Managing Details Templates.

So, you're trying to customize the properties pages of your address lists and want to add an attribute such as ipPhone. You don't see the attribute you're looking for. Can you add additional attributes to the list? Or should you? Dave Goldman explains in Adding attributes to the Exchange details templates.

Exchange Server 2007: Listing Exchange ActiveSync users and device information

In How to get a list of Exchange ActiveSync users we list EAS users on Exchange 2007. Some users may have more than 1 device, or perhaps the user simply got a new smartphone and the old device partnership has not been removed.

Output from Get-ActivesyncDeviceStatistics -mailbox foo@somedomain.com:

FirstSyncTime : 12/22/2007 1:34:10 AM
LastPolicyUpdateTime : 12/22/2007 1:34:43 AM
LastSyncAttemptTime : 1/14/2008 7:45:15 AM
LastSuccessSync : 1/14/2008 7:45:15 AM
DeviceType : PocketPC
DeviceID : *******************************
DeviceUserAgent :
DeviceWipeSentTime :
DeviceWipeRequestTime :
DeviceWipeAckTime :
LastPingHeartbeat :
RecoveryPassword : ********
DeviceModel : WIZA100
DeviceIMEI : ************21900
DeviceFriendlyName : Pocket_PC
DeviceOS : Windows CE 5.2.19134
DeviceOSLanguage : English
DevicePhoneNumber : 1650*******
Identity : foo@somedomain.com\AirSync-PocketPC-*******************************

The * characters in the Identity field are for the DeviceID.

Here's a a quick code snippet (it can probably be scrubbed up a little... ) that will list users and all their devices, along with first sync and last successful sync times:

$mbx = get-casmailbox | where {$_.hasactivesyncdevicepartnership -eq $true -and $_.identity -notlike "*CAS_{*"} ; $mbx | foreach {$name = $_.name; $device = get-activesync devicestatistics -mailbox $_.identity; $device | foreach {write-host $mbx.name, $_.devicemodel, $_.devicephonenumber, $_.deviceid, $_.FirstSyncTime, $_.LastSuccessSync} }

Update: 10/2/2008:
Making it more efficient: Filtering on the server-side using -Filter
Well, the above code could be scrubbed up a little. Rather than getting all mailboxes using Get-CASMailbox and filtering them on the client-side using the Where-Object cmdlet, a more efficient way of doing this is filtering on the server-side using the -Filter parameter, and getting only the mailboxes which have an ActiveSync device partnershp.

Yes, I've just realized HasActiveSyncDevicePartnership is in fact a filterable property, listed under Advanced Filterable Properties in Filterable Properties for the -Filter Parameter in Exchange 2007 SP1.

Here's the updated version:

$mbx = get-casmailbox -Filter {HasActivesyncDevicePartnership -eq $true -and -not DisplayName -like "CAS_{*"}; $mbx | foreach {$name = $_.name; $device = get-activesync devicestatistics -mailbox $_.identity; $device | foreach {write-host $mbx.name, $_.devicemodel, $_.devicephonenumber, $_.deviceid, $_.FirstSyncTime, $_.LastSuccessSync} }

The output looks like this:

Bharat Suneja WIZA100 16501231234 353B7ACF5014C020CE22CBF1DB7FFD92 11/5/2007 7:41:29 AM 12/20/2007 11:00:15 PM
Bharat Suneja WIZA100 16501231234 7E6B67F47DFD370E89BE13280A75EAA5 12/22/2007 1:34:10 AM 1/14/2008 7

Related posts and links

• Cmdlet: Get-ActiveSyncDeviceStatistics
  
• Cmdlet: Get-CasMailbox

Starting Task Manager in RDP or VM sessions

You have a RDP (Terminal Services) session or a Virtual Machine session open, where the CTRL-ALT-DEL key combination fires up the Windows Logn/Security dialog on the host computer rather than the RDP or VM session you have open.

Getting to the Task Manager involves some mouse-clicks in such situations— Start -> Windows Security -> Task Manager (works in both RDP and VM sessions) or clicking on the appropriate shortcut in the VM client software. Hyper-V has a short-cut on its menu bar that makes it a single mouse click, but still not quick enough. It's actually annoying if you are happily pounding away at the keyboard for most part... and now need to lift your hand to grab a mouse and... you know where we're going with this!

Shorcuts exist - if you're at the cmdline, you can simply type taskmgr.exe (or Start -> Run -> type taskmgr.exe). Alternatively, you can create a desktop shortcut and point it to taskmgr.exe. If you simply want to remain at the cmdline and not bother with the GUI at all, use TaskList. You can filter the output in a number of ways - use tasklist /? to see all the options.

If you're on an Exchange 2007 box or have Windows PowerShell installed, it gets event better. Get-Process and Stop-Process commands are your friends here. You can filter by process name or PID, and also pipe the output from Get-Process to Stop-Process. For example:

Get-Process -Name svchost
Get-Process -Name MSExchange* | ft Id,Name,Handles,PM -AutoSize
Get-Process | ft Name,Company,ProductVersion,FileVersion -Autosize
Stop-Process -ID 6064
Get-Process mmc* | where {$_.Handles -gt 1000} | stop-process

Quick antispam report or status check?

Having received an annoyingly higher proportion of spam in my Inbox this morning, I wanted to quickly check what the antispam agents are doing. Here's a quick cmdlet (besides the ones to check whether the antispam agents are enabled, checking the Content Filter SCL thresholds, etc.).

Get-AgentLog -StartDate "6/16/2008" | group action | ft name,count -Autosize

What you get back:

Name Count
---- -----
RejectCommand 520
AcceptMessage 39
RejectMessage 163
QuarantineMessage 11
DeleteMessage 21

The filters are still working. Perhaps it's one of those days when you wake up to high volume of spam.

Note to self: Create a quick monitoring script that provides more information from agent logs, antispam configs, and perfmon counters.

Related posts:
- Keeping tabs on Antispam filters: A few handy scripts in Exchange Server 2007
- Exchange Server 2007: How are RBLs performing?
- Exchange Server 2007: Managing And Filtering Anti-Spam Agent Logs

Announced: Plug-in for Exchange backups on Windows Server 2008

Windows Server 2008's new Windows Server Backup utility, the replacement for NTBackup, doesn't do Exchange backups out of the box.

I'm in Scott Schnoll's session where he just announced a new Microsoft plug-in that will do Exchange VSS backups. The tool will be released this summer.

More notes from this excellent session soon!

Perfmon counters show up as numbers?

You're troubleshooting an important issue and fire up Performance Monitor, only to be greeted by this bizarre visual— all your Perfmon counters show up as numbers! You restart Perfmon a few times, try to choose a different performance object - but it's still numbers.


Figure 1: Performance Monitor counters and objects are displayed as numbers instead of object and counter names

Fix:

Lodctr.exe /r

It can take a little while (about 10 minutes in this case).

Released: MAPI Client and CDO 1.2.1 for Exchange 2007

The Exchange Server 2007 base package does not include MAPI client libraries and CDO components that can be used by applications. MAPI and CDO are used to programmatically connect to Exchange Stores. These have been released as a web download.

Download ExchangeMapiCdo.MSI from microsoft.com.

Removing internal host names and IP addresses from message headers

Another frequently asked question about SMTP mail - how can I remove internal host names and IP addresses from outbound internet mail? More often than not, this results from the belief that somehow if the outside world finds out an organization's internal IP addresses and host names, it makes the organization vulnerable. Auditors love to point this out for some reason. Perhaps it's a part of a checklist written by a security expert at some law firm somewhere, and given the viral nature of checklists it's all over the place!

Let's take a look at what we're talking about here. As a message makes its way from one server to another, it may be handled by more than one SMTP hosts. Each host adds a RECEIVED header at the beginning of message headers, leaving a trace of where the message has been and when (a timestamp).

Here are headers from a message received from Dell. (Unnecessary headers removed).

Received: from smtp.easydns.com (205.210.42.52) by exchange.somedomain.com
(192.168.2.171) with Microsoft SMTP Server id 8.1.240.5; Mon, 19 May 2008
03:12:46 -0700
Received: from mh.dell.m0.net (mh.dell.m0.net [209.11.164.66]) by
smtp.easydns.com (Postfix) with ESMTP id 647C222914 for ;
Mon, 19 May 2008 06:14:46 -0400 (EDT)
Received: from [192.168.138.130] ([192.168.138.130:57330]
helo=fc13a1.dc1.prod) by oms1.dc1.prod (ecelerity 2.1.1.24 r(19486)) with
ESMTP id 3B/AF-18306-11351384 for ; Mon, 19 May 2008
03:14:41 -0700
Message-ID: <14154167762.1211192081379@delivery.net>
Date: Mon, 19 May 2008 03:14:41 -0700
From: Dell Small Business
Reply-To:
To:
Subject: $429 desktop, plus new laptops. Hurry and shop now.
Errors-To: dell@smallbusiness.dell.com
Return-Path: dell@smallbusiness.dell.com

These headers can be used to determine the path taken by a message— useful information for troubleshooting and preventing message loops.

What the standards say
Let's take a look at what the standards say. RFC 2821 says (capitalization of words as it appears in the RFC, emphasis added):

4.4 Trace Information

When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in section 4.1.1.4.

This line MUST be structured as follows:

- The FROM field, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

and prohibits removing received headers (repeatedly). One example:

An Internet mail program MUST NOT change a Received: line that was previously added to the message header. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location.

More secure?
Should you remove these headers, and "hide" internal hosts and IP addresses? Is it really a security risk?

There are many opinions about security through obscurity, but if your security relies on hiding internal hostnames and IP addresses, you probably have other things to worry about.

Steve Riley, Senior Security Strategist at Microsoft, says:

In general, you can’t achieve any additional security by trying to hide things that weren’t designed to be hidden. IP addresses, wireless SSIDs, hostnames—these are all identifiers, and by definition, an identifier is intended to be known. Efforts to hide them generally fail, because the thing that the identifier points to still exists! Determined attackers will find the thing regardless of what you name it.

Microsoft does not remove internal message routing headers. Nor do Dell (as the message headers in the example above reveal), HP, and many other large organizations.

In many ways, the issues faced are similar to changing fqdn on SMTP Virtual Server/Receive Connector. Even if you make these changes, at least one internal hostname is likely to be revealed by the Message-ID (read "Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain").

Nevertheless, many organizations may have a legitimate need to cleanse outbound mail of internal host names and IP addresses, and you probably don't want to invite adverse remarks in an IT or compliance audit (should you find such a requirement on the auditor's checklist).

How to remove Received headers in Exchange Server 2007
Exchange Server 2007 offers an easy way to accomplish this. If your transport server sends outbound email directly using DNS lookup, or delivers to a smarthost without authentication, simply remove the Ms-Exch-Send-Headers-Routing permission assigned to Anonymous Logon— a well-known security principal that refers to anonymous users, as shown below:

Get-SendConnector "Connector Name" | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights "ms-Exch-Send-Headers-Routing" -user "NT AUTHORITY\Anonymous Logon"

What's your take?
Does your organization remove internal Received headers? What are the reasons cited? Does removing internal received headers make your organization more secure? Feel free to leave a comment and share your opinion about this.

Released: Update Rollup 2 for Exchange Server 2007 SP1

Exchange Server 2007 SP1 Update Rollup 2 has been released.

Description of the roll-up can be found in KB 948016. Besides all the fixes from Update Rollup 1 (for SP1), this rollup includes fixes for the following issues:

• - 940462 The public folder store may take several minutes to mount on an Exchange 2007 server
• - 944153 Exchange Server 2007 does not have Transport Neutral Encapsulation Format (TNEF) capabilities for POP and IMAP protocols
• - 945917 You receive an error message when you try to access the Outlook Web Access global address list in an Exchange Server 2007 environment
• - 947346 Exchange Server 2007 mailbox users cannot retrieve the free/busy information for Exchange Server 2003 mailbox users in a large Exchange Server organization that has more than 100 administrative groups
• - 947360 Error message occurs, and users cannot access the free/busy information after you use the Import-Mailbox cmdlet to import data to a mailbox in Exchange Server 2007 Service Pack 1
• - 947391 The contents of .pst files are not imported into Exchange Server 2007 mailboxes when you use the Import-Mailbox cmdlet
• - 947451 A recipient sees unexpected text in the top of an e-mail message that you send in Exchange Server 2007
• - 947458 The Edgetransport.exe process may crash on an Edge server that is running Exchange Server 2007 Service Pack 1
• - 947551 The Edgetransport.exe process may crash intermittently on an Exchange Server 2007 Service Pack 1 Edge server
• - 947577 If you try to connect a mobile device to a mailbox server through a server that is running Exchange Server 2007, the mobile device may be unable to connect
• - 947646 Event ID 12011 is logged every time that the MSExchangeTransport service starts after you install Exchange Server 2007 Service Pack 1 on a computer that is running the German version of Windows Server 2003
• - 948047 An event ID 1080 message is logged in the System log every three seconds after you run the Set-ExchangeServer command to set the static domain controllers on an Exchange 2007 cluster node
• - 948297 The OOF template may be delivered as an attachment in an Exchange 2007 environment when you use the "Reply with Template" option in Microsoft Outlook
• - 948332 Failover takes a long time to finish in an Exchange Server 2007 cluster continuous replication environment
• - 948374 The EdgeTransport.exe process crashes intermittently, and event ID 1033 is logged in Exchange Server 2007
• - 948666 When you try to migrate a mailbox from Exchange Server 2003 to Exchange Server 2007, the Exchange Management Shell may stop responding
• - 948830 The MSExchangeSyncAppPool application pool crashes on a server that hosts an Exchange Server 2007 Client Access Server role
• - 948831 A user may be unable to synchronize with an Exchange Server mailbox from a mobile device when a Client Access server has been upgraded to Exchange Server 2007 Service Pack 1
• - 948844 An exception occurs, and event IDs 4999 and 5000 are logged when you modify the Outlook Web Access user interface
• - 949186 When you try to run the Restore-mailbox cmdlet on a server that is running Exchange Server 2007, you receive an error message
• - 949193 The address rewrite agent does not rewrite the address for Out of Office (OOF) messages in Exchange Server 2007
• - 949463 An exception error is generated after you run a Set-AttachmentfilterListConfig command together with the ExceptionConnectors option on an Exchange 2007 SP1-based server
• - 949541 You cannot log on to Outlook Web Access Light, and an error message occurs in Exchange Server 2007
• - 949703 Error message in Outlook when you click the signature icon of a signed e-mail message that an Exchange Server 2007-based Edge server receives: "The digital signature is invalid"
• - 949726 After you install Exchange Server 2007 Service Pack 1, the Set-ExcecutionPolicy task causes an error message, and event ID 103 is logged
• - 949772 If you run the "isinteg -dump" command against a dismounted store on a server that is running Exchange Server 2007, the Store.exe process stops unexpectedly
• - 950123 Error message after you apply Update Rollup 1 for Exchange Server 2007 Service Pack 1 in a Japanese environment: "Public Folder Management Console is not an allowed Snap-in"

HOW TO: Remove the Public Folder Store

This is a fairly common question - you're trying to remove the Public Folder store on an Exchange 2007 server and get an error that some Public Folder replicas still exist. You're certain you've removed all Public Folder replicas from that server. What next?

Here's a little procedure documented in How to Delete Multiple Public Folders from Your Organization that takes care of this.

Note: This procedure should be performed only if you're removing the last (or only) Public Folder Store from an Exchange Organization. If there are other servers in the Organization that also host Public Folders, using this procedure removes the folders from the Public Folder hierarchy.

Remove all Public Folder replicas from the server using the following command:

Get-PublicFolder -Server "SERVER NAME" "\" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server "SERVER NAME" -Recurse -ErrorAction:SilentlyContinue

Next, remove all System Folders using the following command:

Get-PublicFolder -Server "SERVER NAME" "\Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server "SERVER NAME" -Recurse -ErrorAction:SilentlyContinue

To verify all Public Folders have been deleted:

Get-PublicFolderStatistics -Server "SERVER NAME" | fl

At times the replica clean-up may take a little while. If you still see replicas after running this command, run it again in 10-15 minutes.

Removing Public Folder replicas using MoveAllReplicas.ps1

If Public Folders are hosted on more than one server, use the MoveAllReplicas.ps1 script to remove replicas from a server, as illustrated in KB 927464: How to remove Exchange 2007 from a computer.

The MoveAllReplicas.ps1 script resides in the Scripts folder in the path where Exchange Server 2007 is installed. It's an easy-to-use script that takes 2 parameters— the source and target server names. The source server is the server you're trying to remove the Public Folder replicas from. The target server can be any other server in the Organization that hosts Public Folders— presumably a server that's in the same location to avoid replicating PFs over WAN links.

MoveAllReplicas.ps1 -Server "SOURCE SERVER NAME" –NewServer "TARGET SERVER NAME"

Once this is done, it may take some time for Public Folders to replicate to the target server, and for these to be removed from the source server. To verify there are no replicas on the source server, you can use the Get-PublicFolderStatistics command.

Errata: Edge Subscription and Synchronization white paper

The white paper on Edge Subscription and Synchronization has the following error:

Under Recipient Information:

Distribution groups are not replicated to ADAM.

Distribution Groups are in fact replicated to ADAM using EdgeSync. In Exchange Server 2007 SP1, Distribution Group membership (the member attribute) is also replicated.

On Windows Server 2008, ADAM is replaced by Active Directory Lightweight Directory Services (AD LDS).

Note that new Distribution Groups created in Exchange Server 2007 are set to receive mail only from authenticated senders by default— preventing them from receiving internet mail. Any Exchange recipients set to receive mail only from authenticated senders are not replicated by EdgeSync.

Related Posts:
- Configuring firewalls and name resolution for Edge Transport servers
- New Distribution Groups do not receive internet email by default

Standby Continuous Replication (SCR): Replay and Truncation Lag

Standby Continuous Replication (SCR) is a new High Availability feature in Exchange Server 2007 SP1. It uses Continuous Replication (also used by LCR and CCR) to replicate Storage Groups from a clustered or non-clustered mailbox server, known as a SCR source, to a clustered or non-clustered mailbox server, known as a SCR target.

SCR is managed using the Exchange shell - no management features exist in the EMC to configure or manage it.

Unlike LCR and CCR, which are designed to have a single copy of a Storage Group (consisting of an Exchange Store EDB + transaction logs & system files), SCR is designed to have many-to-one and one-to-many "replication relationships". (A SCR relationship or partnership - not formally defined terms, but simply used to explain the concept here - is SCR replication of a particular Storage Group from a SCR source server to a particular SCR target server).

A Storage Group from one SCR source can be replicated to multiple SCR target servers, and Storage Groups from one or more SCR source mailbox servers can be replicated to a single SCR target mailbox server.

By default, the Replication Service delays replaying 50 transaction logs to the SCR replica Database. Additionally, you can configure the following parameters to control how SCR replicas behave:
ReplayLagTime: specifies how long the Replication Service waits before replaying replicated transaction logs to the replica Database (EDB) on the target. Default:1 day
TruncationLagTime sets a lag time for truncating log files on that replica. Provided the other requirements are met for log file truncation on the SCR replica, log files are not truncated till ReplayLagTime + TruncationLagTime has elapsed. Default:0.

Why do I need the delay?

Replay lag gives you the protection of having a copy of your database from back in time. This back-in-time copy can be used to recover from logical corruption, pilot errors etc.

Additionally, if there is no delay, in the case of a lossy failover of the SCR source to a LCR or CCR replica, the (new source) Database will be behind its SCR target(s), requiring reseeding. Not something one would want to do for large Databases over WAN links (or even locally within the same datacenter). Delaying the last 50 transaction logs from being replayed to the SCR target avoids the need to reseed.

However, a large number of transaction logs not replayed to the Database means increased storage requirements for the SCR target, and also an increase in the time it takes to activate it in case of failure of the SCR source. Before it can be brought online, all the logs will need to be replayed.

To avoid this, you can set the ReplayLagTime to 0 (from the default of 1 day). Note, the replay will still lag behind by 50 transaction logs - a hard-coded limit enforced by SCR that cannot be changed. The TruncationLagTime can be set higher, so logs are replayed but not truncated. You can then take VSS snapshots of the target for the point-in-time copies.

Once setup using the Enable-StorageGroupCopy command, the ReplayLagTime and TruncationLagTime cannot be changed without disabling and re-enabling that SCR relationship for the Storage Group.

How can I see ReplayLagTime and TruncationLagTime? The following command shows the SCR targets a Storage Group is being replicated to:

Get-StorageGroup "SG Name" | fl

However, neither the above command, nor Get-StorageGroupCopyStatus show the lag times.

The parameters are returned as an array when you use the former (Get-StorageGroup) - only the name of the SCR target is displayed in the StandbyMachine property.

To see the lag times:

$sg = Get-StorageGroup "MyServer\MyStorageGroupName"
$sg.StandbyMachines

Here's what it looks like:


Figure 1: Displaying the Replay and Truncation lag time

Can I change ReplayLagTime and TruncationLagTime without reseeding the Database? You need to disable replication and re-enable it to add or modify the lag times. :

Disable-StorageGroupCopy "Storage Group Name" -StandbyMachine "SCR Target Server"

When disabling SCR, you get prompted to delete all files in the replica folder on the SCR target. Skip that. Reseeding is not required if you do not delete the files:

WARNING: Storage group "DFMAILMAN.e12labs.com\dfmailman-sg1" has standby continuous replication (SCR) disabled. Manually delete all SCR target files from "C:\Exchange Server\Mailbox\First Storage Group" and "C:\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb" on server "mirror".

Now, let's enable SCR with the replay and truncation lag times:

Enable-StorageGroupCopy "Storage Group Name" -StandbyMachine "SCR Target Server" -ReplayLagTime 1.00:00:00 -TruncationLagTime 2.00:00:00

Once replication is enabled again, make sure to test replication status using:

Get-StorageGroupCopyStatus "SG Name" -StandbyMachine "SCR Target Server"

Routing outbound mail using a particular IP address

A question that frequently and inevitably pops up when discussing Exchange transport is that of being able to route outbound mail using a particular IP address. The Exchange Server 2003/2000 transport architecture was confusing for many newcomers— the difference between an SMTP Virtual Server and an SMTP Connector being the main cause of this confusion. This is further exacerbated by the fact that SMTP Connectors use SMTP Virtual Servers as bridgeheads.


Figure 1: In Exchange Server 2003/2000, the IP address binding in SMTP Virtual Server properties is only for inbound connections

I've often quoted Scott Landry's post on the team blog— SMTP Virtual Server Myths Exposed. Myth #4 in Scott's post:

Myth 4: Virtual Server IP Address Will Be Used For Outgoing Connections

The last source of misunderstanding is the socket which will be used to open an SMTP connection. This may seem confusing and somewhat contradictory of my first point, but SMTP simply tells the Windows network stack to provide SMTP with a socket. It does not provide a source IP address to use, and as such, you will notice that the source IP address assigned by Windows will be based on the Windows routing table, not taking into consideration the IP of the SMTP VSI that is delivering the message. A common observation of this is that on a cluster server we are using the physical machine IP as our source IP, not any of the virtual IP addresses.

Exchange Server 2007, with its shiny new transport stack (freshly divorced from IIS' SMTP service), makes this quite clear. Receive Connectors, somewhat comparable to the SMTP Virtual Server in previous versions, are for receiving inbound mail. Send Connectors are for sending outbound mail.

When creating or modifying a Send Connector using the shell, you can specify the SourceIPAddress parameter to configure it to use a particular IP address for outbound mail. The IP address can be any IP address bound to a NIC on the Edge Transport server that is configured as a source server on the Send Connector. To modify an existing Send Connector, using the following command:

Set-SendConnector "ToInternet" -SourceIPAddress 1.2.3.4

However, as noted in the documentation, this only works on Edge Transport servers. Hub Transport servers ignore the SourceIPAddress parameter.

HOW TO: Delegate recipient administration for an OU

Exchange Server 2007 allows easier delegation of administration responsibilities, based on the following predefined administration roles:
1) Exchange Organization Administrator
2) Exchange Server Administrator
3) Exchange Recipient Administrator
4) Exchange Public Folder Administrator and
5) Exchange View Only Administrator.


Figure 1: Exchange Server 2007 allows delegation of administrative responsibilities

The delegation wizard in the EMC allows you to delegate the Recipient Administrator role for the entire Organization, but doesn't allow more granular delegation at the Domain or OU level.

More about the Exchange Recipient Administrator role

Security principals that have the Exchange Recipient Administrator role delegated get membership of the Exchange View Only Administrators role. Additionally, they are assigned:
- Read access to all the Domain Users containers in AD (in domains where Setup /DomainPrep has been run)
- Write access to all the Exchange-specific attributes in those domains

When delegating the Exchange Recipient Administrator role using the Exchange console or the Add-ExchangeAdministrator command in the Exchange shell, all you're doing is adding the security principal (user/group) to Exchange Recipient Administrators, a (Universal) Security Group in the Microsoft Exchange Security container in AD.

For more details about Exchange Server 2007 permissions, refer to "Configuring Permissions in Exchange Server 2007".

Here's how you can delegate recipient administration for an OU.
Exchange Organization: E12Labs
Domain: E12Labs.com (DC=E12Labs,DC=com)
OU: San Francisco (OU=San Francisco,DC=E12Labs,DC=com)
User: foo (Best Practice: Assign permissions to Security Groups)

Allow generic read permission for objects in the OU:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericRead

Allow ReadProperty and WriteProperty permissions on Exchange-related attributes for objects in the OU

Add-ADPermission –Identity "ou=San Francisco,dc=E12Labs,dc=com" –User "E12Labs\foo" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail

Property Sets in Active Directory

Exchange-Information and Exchange-Personal-Information are property sets - a number of related properties grouped together. Assigning permissions on a property set results in a single ACE in DACLS, making them much smaller and faster to process.

Exchange Server 2003 adds Exchange attributes to the Public Information and Private Information property sets that exist in Active Directory.

Exchange Server 2007 does not rely on these existing AD property sets, but creates 2 of its own. If deploying in an existing Exchange 2003 Forest, Exchange Server 2007 removes the Exchange properties added to the AD property sets and adds them to the new Exchange 2007 property sets. The Exchange-Information property set has 105 properties. Exchange-Personal-Information has 7. More information about the Exchange Server 2007 property sets and which properties are included in them can be found in "Property Sets in Exchange 2007".

Allow creation and management of Dynamic Distribution Groups in the OU
Exchange Server 2007 RTM:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Exchange Server 2007 SP1:

Add-ADPermission -Identity "ou=San Francisco,dc=E12Labs,dc=com" -User "E12Labs\foo" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList

Allow permission to access RUS:

Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" -User "E12labs\foo" -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents

Allow permission to update Address Lists and Email Address Policies:

Add-ADPermission –Identity "CN=Address Lists Container,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

Add-ADPermission –Identity "CN=Recipient Policies,CN=E12Labs,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=E12Labs,DC=com" –User "E12Labs\foo" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags

In addition to these Active Directory permissions, recipient administrators also need Exchange View Only Administrator permission on the Exchange Organization. Use the following command to assign it:

Add-ExchangeAdministrator "E12Labs\foo" -Role ViewOnlyAdmin

A script for SP1: If you're on Exchange Server 2007 SP1, a script written by Ross Smith IV makes delegating recipient administration permissions on an OU a simple task accomplished quickly (No, it's not for Exchange Server 2007 RTM). The script - ConfigureSplitPerms.ps1, resides in the \Scripts folder in the Exchange Server install path. Usage:

.\ConfigureSplitPerms.ps1 -user "MyDomain\foo" -identity "OU=San Francisco,DC=ExchangeLabs,DC=net"

Released: Exchange Server 2007 Update Rollup 6

Exchange Server 2007 Update Rollup 6 is now publicly available. This update is for Exchange Server 2007 RTM - you do not need to install it on servers running Exchange Server 2007 SP1.

Description of the rollup can be found in KB 942846.

In keeping with the new servicing model for Exchange server (read previous post " Changes to hotfix/patching model for Exchange Server 2007"), rollups are cumulative. They include all the fixes included in previous rollups (Exchange Server 2007 Rollups 1-5 in this case). Update Rollup 6 includes fixes for the following issues:

• - 942814 The account test process is failed when you try to configure an Outlook 2007 client to connect to an Exchange Server 2007 mailbox by using a POP3 connection or an IMAP4 connection
• - 943163 The Test-OwaConnectivity cmdlet and the Test-ActiveSyncConnectivity cmdlet do not run successfully on a computer that is running Exchange Server 2007
• - 943394 Some e-mail messages become stuck in the submission queue in Exchange Server 2007
• - 945428 An e-mail message is in disorder and is unreadable in a Exchange Server 2007 environment
• - 945141 IMAP4 clients may experience latencies or slowness when the clients are running against Exchange Server 2007-based servers
• - 945046 You receive an NDR message when you send an e-mail message by using a Exchange Server 2007 Edge server
• - 941805 Error message when you try to schedule a yearly recurring appointment on the 31st day of certain months: "The recurrence date is invalid"
• - 944451 Only the entries in the MailSubmission log are returned when you run the Get-MessageTrackingLog cmdlet against an Exchange 2007 server that hosts both the Hub Transport role and the Mailbox role
• - 944333 The store event sink does not run as expected in an Exchange Server 2007 environment
• - 942374 Legacy free/busy information no longer appears for appointments that are booked against a mailbox in Exchange Server 2007
• - 940053 Error message when a user tries to access a mailbox and download e-mail messages by using a DAV e-mail client program: "HTTP 500 - Internal server error"
• - 941655 The Store.exe process stops responding, and event ID 9659 is logged on an Exchange 2007 server
• - 942424 On an Exchange Server 2007-based computer, the Microsoft Exchange Information Store service stops unexpectedly when you start the service or when you mount a database store
• - 941851 An HTML e-mail message appears garbled in Outlook when you send the message to an Exchange 2007 user
• - 935894 Web beacons and HTML forms in e-mail message attachments are blocked regardless of the FilterWebBeaconsAndHtmlForms parameter setting for the Outlook Web Access virtual directory in Exchange 2007
• - 943264 The IMAP service returns an untagged EXISTS response before the EXPUNGE command in Exchange 2007
• - 943149 You cannot type the Polish character "?" in the Subject box, in the To box, or in the Cc box when you compose an e-mail message in Outlook Web Access for Exchange 2007
• - 943371 Event IDs 8206, 8213, and 8199 are logged in an Exchange 2007 environment
• - 942647 The display name of an e-mail address is not encoded correctly according to RFC 2047 when you use extended characters in Exchange 2007
• - 943479 Some source mailboxes are merged into one target mailbox after you use a Move-Mailbox cmdlet to migrate the mailboxes from an Exchange 2003 organization to an Exchange 2007 organization
• - 944321 The Edgetransport.exe process may stop unexpectedly on an Exchange Server 2007-based edge server
• - 938957 The GetItem operation in Exchange Web Service obtains duplicate strings in Exchange 2007
• - 942418 The Subject line of a delegate e-mail message is corrupted in Outlook 2007
• - 925252 The Store.exe process uses almost 100 percent of CPU resources, and the size of the public folder store increases quickly in Exchange 2007

Exchange Server 2007 Rollup History

At 24 new fixes, this is the biggest rollup of them all. Here's what the previous rollups fixed:

Rollup 1 (4/18/2007): This is a minor rollup with 3 issues fixed - 932487, 929756, 930572
Rollup 2 (5/8/2007): Released within 3 weeks of the previous Rollup, it fixes a security issue mentioned in Microsoft Security Bulletin MS07-026 - Vulnerabilities in Microsoft Exchange Could Allow Remote Code Execution (931832)
Rollup 3 (6/28/2007): 14 issues fixed - 931328, 930468, 931842, 932207, 932515, 934887, 936337, 932905, 934402, 935412, 934259, 932605, 932661, and 935202
Rollup 4 (8/23/2007): 11 issues fixed - 930463, 937656, 936300, 932561, 937861, 938359, 940052, 933314, 939560, 938698, and 936716
Rollup 5 (10/25/2007): 14 issues fixed - 940051, 940058, 936734, 938130, 940080, 940632, 940757, 940764, 941104, 940259, 941774, 940710, 940329 and 941552
Rollup 6 (2/21/2008): 24 issues fixed, as listed in the above section.

How to forward mail to an external email address

In Exchange Server 2003, mail for a recipient can be forwarded to an alternate recipient by modifying the recipient's Delivery Options in ADUC | recipient -> properties | Exchange General tab.

If you need to forward mail to an external email address, you cannot simply type the address in Delivery Options. A (mail-enabled) Contact needs to be created in AD first, and Delivery Options modified to point to the Contact.

Exchange Server 2007: In Exchange Server 2007, these tasks remain the same. However, instead of using ADUC to accomplish them, you use the EMC or the shell (aka "EMS"). The new term for a Contact is MailContact.

 To create a MailContact using the Exchange Management Console:

1. Expand Recipeint Configuration | Mail Contact
2. In the Action pane, click New Mail Contact
3. To create a new Contact object, leave the default (New Contact) selected | click Next
4. Type First name, Last name
5. Click Edit to add the external email address
6. Click New to complete creation of new MailContact

To create a new MailContact using the Exchange Management Shell:

New-MailContact -Name "Foo User" -ExternalEmailAddress "foo@externaldomain.com

Next, we set the recipient's Delivery Options to deliver to the alternate recipient.

 To forward mail for a recipient to the MailContact using the Exchange Management Console:

1. Expand Recipeint Configuration | Mailbox | select mailbox | properties | Mail Flow Settings tab | Delivery Options
2. Under Forwarding address, select the Forward to checkbox
3. Click Browse to select the MailContact

Figure 1: Modifying Delivery Options to forward email to an alternate recipient

4. Optional: If a copy of the message needs to be delivered to both the external recipient and the original recipient's mailbox, select the Deliver message to both forwarding address and mailbox
5. Click OK to close Delivery Options properties
6. Click OK to close recipient's properties

Using the Exchange Management Shell:

Set-Mailbox "Joe Adams" -ForwardingAddress "foo@externaldomain.com"

To deliver a copy to the mailbox (in addition to the external email address - equivalent of step 4 above):

Set-Mailbox "Joe Adams" -ForwardingAddress "foo@externaldomain.com" -DeliverToMailboxAndForward $true

To get a list of mailboxes with forwarding enabled:

Get-Mailbox | where {$_.ForwardingAddress -ne $null} | ft name,forwardingaddress

Automatic forwarding and Remote Domains

Remote Domains are a bunch of settings, such as message formats, character sets, and OOFs, for messages sent to particular remote domains. The default Remote Domain setting applies to address space * - that is, all remote domains for which an explicit Remote Domain setting does not exist.


Figure 2: The Allow automatic forward setting for remote domains impacts client-side automatic forwarding, and is disabled by default.

However, this setting only applies to client-side forwarding. For instance, if a user creates a rule in Microsoft Outlook to automatically forward mail to an external email address, the default setting does not allow it. To enable automatic client-side forwarding of mail to external addresses, select the Allow automatic forward checkbox in a remote domain's properties | Format of original message sent as attachment to journal report tab (Yes, the tab is mislabeled. It is the "Message Formats" tab... :).

Server-side forwarding setup by an administrator is not impacted by this setting.

DST 2007: December 2007 cumulative time zone update for Microsoft Windows operating systems

The last time we took a look at the timezone changes was when the August 2007 cumulative time zone update was released (Read previous post: "DST 2007: August 2007 Cumulative Timezone Update for Windows operating systems"). The August 2007 update included new timezone data for Caucasus Standard Time, Armenian Standard Time, New Zealand Standard Time, GTB Standard Time, and Jordan Standard Time. Some updates were minor - such as changing the display name of a time zone.

In December, Microsoft released another time zone update - KB 942763: December 2007 cumulative time zone update for Microsoft Windows operating systems. Changes:
- Arabic Standard Time: Adjusts DST start and end dates for Baghdad time zone
- Australia: Central Australia, Eastern Australia and Tasmania Standard Time - these start and end on the same day.
- Egypt Standard Time: Adjusts DST start and end dates for Cairo time zone
- Israel Standard Time: Adjusts DST start and end dates for Jerusalem
- South America: E. South America Standard Time, Central Brazilian Standard Time - Adjusts DST start dates and end dates for the Brasilia time zone and for the Manaus time zone
- Venezuela Standard Time: Adds a new time zone for the Caracas time zone

Updates in the above list reflect the latest time zone changes made around the world after the Aug. 2007 Cumulative Timezone Update was released. If you've already applied the previous updates affecting your locale, and rebased appointments, the latest update will not change anything for you.

Also note, this is a cumulative update. It includes all previous timezone updates.

Related posts:
- DST 2007 Rollup Post

Exchange Server 2007 SP1: The most obscure (but relevant) changes

Recently I was asked by a fellow MCT (and now Exchange MVP) to list 3 most obscure (but relevant) changes in Exchange Server 2007 SP1. The first thing that came to mind was the change made to Back Pressure settings.

Back Pressure stops inbound mailflow on transport servers if system resources fall below a certain level. In Exchange Server 2007 RTM, the threshold for free disk space was 4 Gigs - if you had less, Back Pressure (yes, there have been jokes about the name of this feature... ) stops inbound mailflow and throws a 452 4.3.1 Insufficient system resources error on mail submission. Read previous post Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources for my experience with this.

In SP1, the threshold has been reduced to a much more realistic level of 500 Mb. I can probably live with that.

I later posted about turning Back Pressure off - not necessarily something I recommend in production. However, in test environments (particularly in virtual server environments with disks created to be the smallest size possible to allow installation of Windows Server and Exchange... ) this generally makes sense.

Related posts:
- Exchange Server 2007 Transport: 452 4.3.1 Insufficient system resources
- Exchange Server 2007: How to turn off the Back Pressure feature on transport servers

Exchange Server 2007: Renewing the self-signed certificate

Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.

The self-signed certificate meets an important need - securing communication for Exchange services by default. Nevertheless, one should treat these self-signed certificates as temporary. It's not recommended to use these for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).

However, should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these need to be renewed - just as you would renew certificates from 3rd-party or in-house CAs.

 To renew the certificate for server e12postcard.e12labs.com, a server with CAS and HT roles installed:

Get-ExchangeCertificate -domain "e12postcard.e12labs.com" | fl

Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.

Get a new certificate with a new expiration date:

Get-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F" | New-ExchangeCertificate

If the existing certificate is being used for SMTP, you will get the following prompt:

Confirm
Overwrite existing default SMTP certificate,
'C5DD5B60949267AD624618D8492C4C5281FDD10F' (expires 8/22/2008 7:20:34 AM), with certificate '3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E' (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Type y to continue. A new certificate is generated.

Thumbprint   Services   Subject
----------   --------   -------
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E   .....   CN=E12Postcard

The new certificate is generated and enabled. Examine the new certificate:

Get-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" | fl

 The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP - IIS is missing.

To enable the certificate for IIS:

Enable-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" -services IIS

This enables the certificate for IIS (in addition to any other services it may already be enabled for - it adds to existing values of the services property).

 Test services are working with the new certificate. If it works as expected, the old certificate can be removed:

Remove-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F"

Related posts:
- Outlook Anywhere and Exchange's Self-Signed Certificate
- Which name should I use as Common Name for my UC certificate?
- DigiCert: A Certificate Authority with excellent customer service

Assigning SCL to messages scanned by 3rd-party antispam filters

Here's a problem I had a hard time resolving on Exchange Server 2003. Exchange Server 2007's Transport Rules resolve this within minutes.

Pretend you're taking a Microsoft exam:
Scenario: "You are the Exchange administrator for your organization... ".

Exchange has the Content Filter Agent (CFA), and the Edge Transport Server role designed to be a non-domain-joined mail gateway, located in perimeter networks. However, the Unix/Linux/Security folks in your organization don't trust Exchange to do the filtering (or act as the mail gateway). They insist on using open source anti-spam software, such as SpamAssasin (yes Eric, I remember CRM114 - the Controllable Regex Mutilator... and all the cool stuff you can command it to do. Just to set the record straight, I was suitably impressed back then, and continue to be so till this day.. :) on the non-Exchange SMTP gateways. After tweaking it for a number of weeks, they are able to make it work the way they want it to, or are close to it. It's implementation time!

Their solution is to insert an X-header in messages that looks like this:

X-Spam-Status:yes

That's it. Their job ends there.

As the Exchange team/administrator, your job is to ensure messages with that header end up in users' Junk Mail folder.

Exchange Server 2003 did not provide any way, out-of-the-box, to be able to inspect message headers and stamp SCL. To add some contextual fun - back then, our "solution" was a doc that showed the end-users how to create an Outlook rule to move such messages to Junk Mail. Only if Exchange/Windows admins could code... I can hear you think.

 Creating a Transport Rule: Exchange Server 2007's Transport Rules functionality allows you to accomplish this easily. Here's how:
1. Fire up EMC | Organization Config | Hub Transport | Transport Rules tab
2. Click on New Transport Rule in the Action pane
3. Give the new rule a name, add a comment if you wish
4. In the Conditions page, select the condition when a message header contains specific words
5. In the Step 2 edit box, click on the message header link

6. Type X-Spam-Status | click OK
7. In the edit box, click on the specific words link
8. Type yes | click OK | click Next
9. In the Actions page, select the action set the spam confidence level to value
10. In the rule description, click on the 0 link and add a value that's above your SCLJunkThreshold | click Next
11. On the Exceptions page, click Next if you do not want any exceptions to this rule
12. Click New | click Finish to close the wizard

Or you can use the following commands:

$condition = Get-TransportRulePredicate HeaderContains
$condition.MessageHeader = "X-Spam-Status"
$condition.words = @("yes")
$action = Get-TransportRuleAction SetSCL
$action.SCLValue = 5
new-TransportRule "Stamp SCL" -condition @($condition) -action @($action)

 Disabling the Content Filter agent: Since you have a 3rd-party filtering solution running on your non-Exchange SMTP host(s), you can disable the Content Filter Agent. Messages exceeding SCLJunkThreshold will still be moved to Junk Mail folder.

Disable-TransportAgent "Content Filter Agent"

Alternatively, you can leave the CFA enabled, but disable the Delete, Reject and Quarantine actions.

Set-ContentFilterConfig -SCLDeleteEnabled $false -SCLRejectEnabled $false -SCLQuarantineEnabled $false

Send a test message with the X-header X-Spam-Status:yes. The message has the SCL value set by the Transport Rule. If it is above the SCLJunkThreshold, it should be delivered to the Junk Mail folder.

Why this doesn't work with Delete, Reject or Quarantine thresholds enabled?

The Content Filter Agent fires on the EndOfData SMTP event. On Hub Transport servers, the Transport Rules Agent fires on the OnRoutedMessage event. If the CFA is left enabled, along with any of the above actions, messages may get deleted, rejected or quarantined. The Transport Rules Agent never gets to see deleted and rejected messages at all.

What about quarantined messages?

It's understandable if the message is already deleted or rejected - there's nothing left for the Transport Rule agent to act on! However, why doesn't the agent act on quarantined messages? With Pipeline Tracing turned on, I spent some precious cycles trying to unravel the mystery, with little success. As it turned out (thanks to helpful Exchange team folks for pointing out... ), I was overlooking the obvious - Quarantined messages are wrapped in an NDR "envelope". If you've ever logged into the quarantine mailbox and looked at quarantined messages, you know what these look like. (Related post: "HOW TO: Expose original senders and recipients of quarantined messages") The Transport Rules Agent does not see the original message headers, including our X-Spam-Status header. As a result, the rule never fires.

Life on the Edge

If using an Edge Transport server in the mix, things change. The Edge Rule agent fires on the EndOfData event, unlike Hub Transport servers. When two transport agents fire on the same SMTP event, you can set the priorities of each accordingly so one fires before the other. This is described in "How to Make the SCL Value Available to Edge Transport Rules" in Exchange Server 2007 documentation.

However, it's a lot simpler to just disable the Content Filter Agent. This meets the requirements of this scenario, where anti-spam filtering is done by 3rd-party anti-spam filters and Exchange isn't required to do any filtering at all.

SMTP Connector Myth: Messages are always routed over SMTP Connectors with more specific address spaces

An Exchange Server message routing myth forever being propagated (including by me!):

If 2 SMTP Connectors (or Send Connectors in case of Exchange Server 2007) exist, one with a more specific address space, like exchangepedia.com, and one for a more generic address space like *, messages are always routed over the Connector with the more specific address space.

Now, generally that rule of thumb works for most purposes, until you consider restrictions on Connectors. These include:
Connector Scope: (Entire) Organization, or the Routing Group (to which the Connector belongs or is homed to)
Message Size restrictions: To prevent messages over a certain size from being routed over a Connector
Delivery Restrictions: To allow/prevent messages from particular senders from being routed over a Connector (Exchange Server 2003/2000)


Figure 1: Content Restrictions on a SMTP Connector, including message size limit

Scenario:
You want to prevent users from sending messages over 100 Kb to exchangepedia.com.
- Connector1 for address space exchangepedia.com, message size restriction of 100Kb.
- Connector2 for address space *, no message size restrictions.
Result:
- Messages for exchangepedia.com recipients with a message size that is under the 100kb limit are routed over Connector1.
- Messages for exchangepedia.com recipients with a message size of over 100kb are routed over Connector2 with the generic address space of *. Connector1 with more specific address space of exchangepedia.com is never considered.

If you want to limit messages sent to exchangepedia.com to only 100kb, you cannot do it using the configuration in the above scenario.

From Exchange Server 2007 documentation:
Routing to External Domains -> Selecting the Routing Path to an External Recipient):

If more than one Send connector is configured to have an address space that meets the routing requirements for an external recipient, Exchange 2007 routing will select a single connector through which to route the message. The selected connector must meet the message size constraints. After Exchange 2007 has eliminated all connectors that have prohibitive message size restrictions, routing applies the following criteria to determine to which connector it will route:

From the list of all Send connectors and foreign connectors that are configured in the Exchange organization, it narrows the list to connectors that satisfy all the following criteria:

- In the scope for the local server
- Enabled
- With an address space that matches the recipient's e-mail domain

From the resulting list, select the connector with the most specific address space match. No matching connectors may be found.

Maybe an Exchange Server 2007 change, you wonder. Not quiet - Exchange Server 2003 behaves similarly.

From Exchange Server 2003 documentation:
Exchange Server 2003 Message Routing -> Routing Path Selection Process

It determines all connectors to the message destination in the organization topology, and then analyzes message characteristics and connector restrictions to exclude all those connectors that must not be used to transfer the message.

In a nutshell: Connector selection happens after restrictions are checked.

Which Connector? Determining the Send Connector used in Exchange Server 2007 is quiet easy - if using different fqdns on a Send Connector, you can simply check the Received headers; or you can look at the SMTP logs (read previous post "Exchange Server 2007: Logging SMTP Protocol Activity"). In Exchange Server 2003, you can bump up the diagnostics logging on MSExchangeTransport -> Routing Engine/Service. Exchange logs Event ID 984, which provides details about message routing, including the Connector selected.

In the following screenshots, we see 2 different SMTP Connectors being selected for 2 messages to the same destination - the smaller message uses the Connector with the specific address space - exchangepedia.com, which routes the message to a smarthost. The larger message that exceeds that Connector's message size limit is routed using the Connector for address space *, which routes the message using DNS to lookup the MX record(s) for exchangepedia.com.


Figure 2: With Diagnostics Logging enabled, Exchange Server 2003 logs Event ID 984, which shows Connector selected (for a small message under 100kb in this case). The message is delivered to the Smarthost specified in the Connector.


Figure 3: Event ID 984 shows the Connector for generic address space * selected for a larger message (over 100kb in this case). Message is delivered using DNS lookup.

Unintended consequences? The implications aren't pretty, specially when you consider scenarios where one uses a SMTP Connector for a particular address space to enforce TLS (perhaps one of the biggest reasons why messages should never be routed over a Connector with a generic address space if a Connector for a specific address space exists). If I enforce message size restrictions on my Connector with TLS enabled, larger messages can and will be transmitted using the generic Connector that does not use TLS. Now we have the larger message(s) traveling over potentially unsecured SMTP sessions.

What about Delivery Restrictions? For Exchange Server 2003, the same is true for Delivery Restrictions. If the Connector for exchangepedia.com has Delivery Restrictions to prevent Joe Adams from sending messages to Exchangepedia, the message routes over the generic Connector for * - effectively flushing such restrictions down the tube. Restrictions on Connectors with more generic address space are a different story - if Joe has Delivery Restrictions on the * Connector, he cannot send internet mail.

The first task of the Routing Engine/transport should be to check if Connectors with more specific address spaces are available. If it finds any, there is no reason to exclude these from the routing decision. Any restrictions on that Connector exist for a purpose - to restrict message sizes, or to prevent certain users from sending to particular domains using Delivery Restrictions. By excluding Connectors with restrictions from the routing calculation, we're saying routing the message is more important than enforcing those restrictions. As a result, by routing the message over generic Connectors, other requirements for mail delivery to that address space, such as those mentioned above and other available Connector settings, may not be applied.

Related Posts:
- HOW TO: Prevent a user from sending and receiving internet mail
- Exchange Server 2007: Setting Message Size Limits
- Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

Recipient Policies: Can separate policies for Email Addresses and Mailbox Manager Settings be applied?

Exchange Server 2003/2000's Recipient Policies can have settings to generate email addresses for recipients, and Mailbox Manager settings to manage mailbox content. (The Exchange Server 2007 equivalents are 1. Accepted Domains + Email Address Policies to generate email addresses, and 2. Managed Folder Mailbox Policies (with default or custom Managed Folders + Managed Content Settings) to manage mailbox content).

When creating these policies, one can either use a single policy with both types of settings, or use separate Recipient Policies for both purposes - one to generate email addresses for recipients, and other(s) with Mailbox Manager settings to manage mailbox content. The latter approach (separate policies) is more common.

Modifying an existing Recipient Policy to add Mailbox Manager settings

 An existing Recipient Policy can be modified to add/remove Mailbox Manager or Email Address settings by right-clicking the policy and selecting Change property pages.



 From the Property Pages dialog box, select the appropriate settings to be included in the Recipient Policy.

Can multiple Recipient Policies be applied to a recipient?
Yes, you can use separate policies to generate email addresses and manage mailbox content.

Scenario1: Single policy with Email Addresses and Mailbox Manager settings applied. Recipient Joe Adams is not managed by policies (in ADUC -> Joe's account properties | E-mail Addresses tab, Automatically update e-mail addresses based on recipient policy is unchecked). None of the settings - Email Addresses or Mailbox Manager, get applied to that user.

Scenario 2: Two separate Recipient Policies are applied - one with Email Addresses and the other with Mailbox Manager settings. Recipient Joe Adams is not managed by Recipient Policies. The policy with Email Address settings does not get applied to Joe. The second policy with Mailbox Manager settings does get applied.

Given the above scenarios, if you want Mailbox Manager settings to be applied to all mailbox-enabled users, including those that are not managed by Recipient Policies, it makes sense to use two separate policies for Email Addresses and Mailbox Manager settings respectively.

Exchange Server 2007 avoids these scenarios completely. The functionality of generating email addresses - Accepted Domains + Email Address Policies, is separate from the functionality of managing mailbox content, which is available through Managed Folder Mailbox Policies.

Related Posts:
1. Applying Mailbox Manager policies to a sub-folder
2. Exchange Server 2007: Why aren't Managed Content Settngs applied?
3. Applying Managed Folder Policy to more than one user
4. Managed Folders: How to apply different Managed Content Settings to Default Folders
5. Restricting Messaging Records Management to a particular message type

Masquerading SMTP Virtual Servers: Changing the fqdn and masquerade domain

You can change the fully-qualified domain name (fqdn) used by a SMTP virtual server from its properties | Delivery tab | Advanced | Fully-qualified domain name. In the following example, we change the fqdn of a SMTP virtual server from its default - letter.exchangelabs.net, to postcard.exchangelabs.net.


Figure 1: Changing the fully-qualified domain name in SMTP Virtual Server properties

What this does:
1. Changes the fqdn displayed in the SMTP banner.
2. Changes the fqdn provided in HELO/EHLO command when sending outbound mail (see relevant part of a packet capture)
3. The fqdn provided in HELO/EHLO commands shows up in the Received headers in the message.

Delivered-To: foo@gmail.com
Received: by 10.142.188.12 with SMTP id l12cs257007wff;
Tue, 18 Dec 2007 07:24:25 -0800 (PST)
Received: by 10.114.15.1 with SMTP id 1mr2552630wao.27.1197991464897;
Tue, 18 Dec 2007 07:24:24 -0800 (PST)
Return-Path: <jadams@exchangelabs.net>
Received: from postcard.exchangelabs.net (64-169-85-157.ded.pacbell.net [64.169.85.157])
by mx.google.com with ESMTP id m40si5110107wag.2007.12.18.07.24.20;
Tue, 18 Dec 2007 07:24:24 -0800 (PST)
Subject: test fqdn
Date: Tue, 18 Dec 2007 07:22:22 -0800
Message-ID: <086C0984D0478545845025F046CD4E3F037678@LETTER.exchangelabs.net>
From: "Joe Adams" <jadams@exchangelabs.net>
To: "foo" <foo@gmail.com>

What it doesn't do:
- Doesn't change the fqdn used in the Message-ID, as seen in the above headers.

[Act surprised... ]: Now why can't the SMTP VS change the Message-ID as well?
Because RFC 2822 says so - a Message-ID is a globally unique identifier of a message. Once created, the Message-ID for a particular instance of a message should not be changed. It allows one to track messages, and correlate multiple messages to the same thread (using additional header fields like references and in-reply-to).

It's not very often that the SMTP VS encounters messages without Message-IDs. SMTP clients generally generate the Message-ID. When using Outlook (MAPI) or OWA, the Exchange Store generates it. When the SMTP VS sees a message without a Message-ID, it does create one. Try this by telnetting (I'm working on getting this word officially recognized as a verb... :) to the SMTP port of the server, and sending a message. The SMTP VS accepts the messages, and provides you with a Message-ID that uses the changed fqdn.

Changing the fqdn doesn't really "hide" the original fqdn of your server, and the server's IP address is still visible in message headers. As such, it is merely a cosmetic change that doesn't accomplish much in most scenarios. (I frequently refer to and quote Scott Landry's excellent post on the team blog: SMTP Virtual Server Myths Exposed. It's a must-read - Scott addresses the fqdn issue in Myth 3b: Modifying The FQDN of the SMTP Virtual Server).

Does changing the fqdn on the SMTP virtual server ever make sense? Yes, in some scenarios:
- SMTP VS that serves as a Bridgehead for outbound internet mail, if the server's original fqdn uses an invalid or unregistered domain or the hostname has an underscore (_) character (Refer to KBA 841091: Characters that are not supported for object names in Exchange). However, rather than using the default SMTP virtual server for outbound/inbound internet mail, it is recommended to create an additional SMTP Virtual Server for this.
- If the Exchange server has more than 1 SMTP virtual server

SMTP Virtual Server FQDNs and Service Principal Name

If you do decide to change the fqdn on the default SMTP virtual server, ExBPA will warn you about a missing Service Principal Name (SPN) in AD.


Figure 2: ExBPA error: Missing Service Principal Name. More information

Also take a look at the Kerberos authentication issue that may cause messages to be NDRed with a 550 5.7.1 Unable to relay for foo@domain.com, mentioned in KB 914137: Exchange Protocol Security authentication fails after you install Windows Server 2003 Service Pack 1 on a server that has multiple SMTP virtual servers in Exchange Server 2003.

If the fqdn field does all of the above, what does the Masquerade domain do?


Figure 3: Changing the masquerade domain in SMTP Virtual Server properties

The online documentation provides a hint:

"Use this text box to type an alternate domain for other SMTP servers to use when sending non-delivery reports (NDRs). NDRs will be returned to the alternate domain specified, instead of the domain from which the email originated."

If you change the masquerade domain, restart the SMTP VS and send a test message, chances are you won't see any changes in message headers.

The Masquerade domain setting works when the SMTP VS is a bridgehead for a Connector, and the mailbox that is used to send a message does not reside on the same server.

If it is a Bridgehead for a Connector, the SMTP VS changes the Return-Path header so NDRs are returned to the masquerade domain, as seen in the following headers (irrelevant header fields removed):

Delivered-To: foo@gmail.com
Return-Path: <jonstamp@footimesfive.com>
Received: from letter.exchangelabs.net (64-169-85-157.ded.pacbell.net [64.169.85.157])
by mx.google.com with ESMTP id b2si10345244rvf.2007.12.18.07.05.28;
Tue, 18 Dec 2007 07:05:29 -0800 (PST)
Received: from STAMP.exchangelabs.net ([172.31.0.169]) by letter.exchangelabs.net with Microsoft SMTPSVC(6.0.3790.2499);
Tue, 18 Dec 2007 07:03:33 -0800
Subject: Test masquerade from Jonstamp
Date: Tue, 18 Dec 2007 07:03:33 -0800
Message-ID: <AA446FF1A137FA47B5EABE4F94CAC7FD1AE7@STAMP.exchangelabs.net>
From: "Joe Onstamp" <jonstamp@exchangelabs.net>
To: "foo" <foo@gmail.com>
Return-Path: jonstamp@footimesfive.com

Keeping tabs on Antispam filters: A few handy scripts in Exchange Server 2007

One of the more useful improvements in Exchange Server 2007 is the abundance of logging for different features and components (read previous post "Exchange Server 2007: How many logs hath thee?"). In particular, the antispam agent logs fill an important gap in monitoring, reporting and troubleshooting message flow as it relates to antispam agents (read previous post "Exchange Server 2007: Managing And Filtering Anti-Spam Agent Logs"). As a messaging/Exchange administrator, you want to be able to pin point what the antispam agents have been up to, and determine if particular messsages, or sending hosts, domains or email addresses have been blocked by any of the antispam agents. The antispam agent logs and the get-agentlog command allow you to do this quickly and efficiently.

In addition to the the get-agentlog command, Exchange Server 2007 also ships with a number of canned scripts that help you keep tabs on what the agents are doing. These scripts are found in the \Exchange Server\Scripts directory, where \Exchange Server is the path of the Exchange Server 2007 installation. Note, no documentation or support is available for these scripts - they are meant to be examples you can use to write your own scripts. Let's take a peek in the directory and see what we find.

Commandline parameters used by antispam scripts

Most of the following scripts take the same (optional) parameters.
-top n: Where n is the number of results to display. If not specified, the script defaults to (top) 10.
-StartDate: Start date/time
-EndDate: End date/time
-location: path of agent log files. If no path is specified, the agent works against the default agent log file location.

1. Get-AntispamFilteringReport.ps1: Takes one of the following values as a mandatory parameter: 1) connections 2) commands 3) messagesrejected 4) messagesdeleted 5) messagesquarantined, and displays statistics for each agent.
2. Get-AntispamSCLHistogram.ps1: Provides a breakdown of number of messages stamped with each SCL value.
3. Get-AntispamTopBlockedSenderDomains.ps1: Lists top ten sender domains from which mail was blocked.
4. Get-AntispamTopBlockedSenderIPs.ps1: Lists the top ten IP addresses blocked by antispam agents, and number of messages blocked from each.
5. Get-AntispamTopBlockedSenders.ps1: Lists the top ten blocked senders (SMTP email addresses) and number of messages blocked from each. The script can report on P1 (i.e. address in message envelope in the MAIL header) or P2 addresses (from headers in message body like FROM). Specify the option as a commandline argument (optional parameters -top n, -StartDate, and EndDate used in this example):

.\Get-AntispamTopBlockedSenders.ps1 P1 -top 20 -StartDate "12/1/2007" -EndDate "12/10/2007"

Replace the P1 in the above command with P2 to report on P2 senders.
6. Get-AntispamTopRBLProviders.ps1: Lists the top ten RBLs (aka "IP Block List Providers") and messages blocked by each (read previous post: "Exchange Server 2007: How are RBLs performing?").
7. Get-AntispamTopRecipients.ps1: Lists the top ten recipient addresses that receive spam. The addresses may or may not exist in your Organization - the reporting is based on actions taken by antispam agents on incoming messages. Recipient Filtering with Recipient Validation (dropping messages for recipients that do not exist in AD/GAL) is a great way to drop a large number of messages.

The following scripts are not used for reporting:
8. Reset-AntispamUpdates.ps1: Uninstalls any antispam updates and reinstalls the original "out-of-box" antispam data.
9. Install-AntispamAgents.ps1: By default, antispam agents are not installed on the Hub Transport server role (read previous post: "HOW TO: Install anti-spam agents on Hub Transport server"). This script installs them if you need to.
10. Uninstall-AntispamAgents.ps1: Uninstalls antispam agents.

Zenprise at Fenway Park: How the 2007 World Champion Boston Red Sox's IT Shop Keeps BlackBerrys in the Game

I haven't posted too many updates from Zenprise lately. Zenprise v3.3 will ship soon, and the regular stream of customers throughout the year has been a great validation of Zenprise's approach to monitoring and real-time troubleshooting of Microsoft Exchange Server and BlackBerry environments.

The exciting news - standing here during the attendee party at TechEd 2006, I couldn't have thought of this possibility. Yes! The Boston Red Sox became a Zenprise customer earlier this year (Go Red Sox!).

Al Sacco writes about the Red Sox's Zenprise experience in this CIO magazine article.

Excerpts:

Twenty-four/seven connectivity is a must for the 2007 world champion Boston Red Sox's behind-the-scenes champions, and the team counts on a mobile device management (MDM) product from Zenprise to ensure that its BlackBerrys never strike out.

"Within four days of having the product in, we were able to correlate root cause and be able to show ROI from that," Conley says. "Within a month, a problem that was ongoing for five to six months just disappeared." Better yet, he notes, fewer people were calling his team with problems. Instead, the Zenprise tool began offering early warnings on issues so he could report them to users before noticeable problems appeared.

Conley says that since the day his team installed Zenprise for BlackBerry, the Red Sox IT staff has been able to find root causes for every BlackBerry-related issue they've encountered, major or minor, and promptly address those issues with confidence that the suggested fixes will work.

Today, Conley has only one person who spends any of his time—a mere 10 percent—on BlackBerry support. Zenprise does the rest, he says. A year ago, two IT staffers handled BlackBerry support and the organization had only a quarter of the devices it supports today.

Read more on CIO.com: "Eyes on Zenprise: How the 2007 World Champion Boston Red Sox's IT Shop Keeps BlackBerrys in the Game".

Disabled mailboxes: Can they really receive email?

Some truths you live with for a lifetime, like Outlook users cannot send email using an alternate email address (with Outlook in MAPI mode - read previous post: "HOW TO: Send as alternate email address"). Others change as Microsoft Exchange evolves, either through new versions of Exchange server, or service packs and hotfixes.

Disabled mailboxes cannot receive email. Or rather, could not receive email. This has been true all this while, and hasn't changed in Exchange 2000, Exchange Server 2003, including SP1 and SP2.

The reason is described in Microsoft KBA 319047 - "You receive a non-delivery report when you send a message to a disabled account".

In addition to not being able to receive email, administrators face a few other operational issues when managing disabled mailboxes:

- A common scenario: An employee leaves. You disable the account, as part of a standard operating procedure followed in most organizations. You assign his/her manager/co-worker/replacement permissions to access the mailbox. If the mailbox is disabled, they can't access it!
- A disabled mailbox needs to be be enabled first before it can be moved (KBA 278966: "You cannot move or log on to an Exchange resource mailbox")
- The Application Event Log is flooded with annoying Event ID 9548s, informing you that the disabled account does not have a msExchMasterAccountSID attribute populated - something most Exchange administrators have probably gnashed their teeth at a few times a day.

Workarounds exist to populate the msExchMasterAccountSID attribute with the well-known SELF SID (KBA 322890 "How to associate an external account with an existing Exchange 2000 mailbox"), but not something you want to do on a regular interval after every account, or a bunch of them, are disabled.

The hotfix mentioned in KBA 903158: "A hotfix is available to modify the way that Exchange Server 2003 handles a disabled Active Directory user account that is associated with an Exchange Server 2003 mailbox" changes that behavior. It makes the Store act as if a disabled account with a null/empty msExchMasterAccountSID attribute actually has the SELF SID.

All the above actions (and more) complete successfully for disabled accounts. Yes, disabled accounts receive email if you have this hotfix applied - or any subsequent hotfix that updates Store.exe to version 6.5.7234.3 or later.

But what if I don't want disabled accounts to receive email? To prevent disabled accounts from receiving any email, setup Delivery Restrictions (in ADUC | user -> properties | Exchange General tab) to:


Figure 1: Setting Delivery Restrictions on a recipient to prevent receiving mail

1. Receive mail from authenticated users only: With Recipient Filtering enabled, this will drop internet mail at the gateway or the first Exchange server that receives inbound internet mail
2.Receive mail only from: a particular Distribution Group (use a Distribution Group with no members).

Bulk mailbox creation revisited: Adding Active Directory attributes

The instructions in Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell allow you to quickly create mailboxes in bulk using the New-Mailbox command.

Continuing from where we left off in that post, another scenario is being able to add Active Directory attributes to the new user object created by New-Mailbox. Note, the New-Mailbox command can populate only a limited set of AD attributes for an object - those related to Exchange. These are listed in the documentation for New-Mailbox.

To add AD attributes, the logical choice would be to use the New-User command to create the user, and mailbox-enable it by using Enable-Mailbox. This would work great, except for the fact that the New-User command doesn't exist! The key thing to remember is - Exchange provides only the commands necessary to create Exchange recipients. So you have commands like New-Mailbox, New-MailUser, New-MailContact, New-PublicFolder/New-MailPublicFolder, and New-DistributionGroup. However, there are no AD-equivalents like New-User, New-Contact (to create a Contact that's not mail-enabled), New-SecurityGroup or New-Group.

PowerShell and Active Directory

Active Directory isn't really PowerShell-enabled, as other components of Windows - like the file system, registry, etc., and Exchange Server 2007 are. There are no AD-related commands (Cmdlet? Shell folks, was it really necessary to introduce another word to the jargon - one that uses the entire word "command"? Perhaps something shorter would've been nicer if you wanted to have a unique word... :-) You can use the Directory Services provider, but that essentially leaves you in VBScript mode, with some PowerShell goodness! A little easier, but not natively shell, as you are used to with Exchange commands.

Quest adds these much-needed commands through its free add-on Management Shell for AD. Download it here. Quest has named them so they're differentiated from future commands that will be available natively in PowerShell. For the time being, the quirkiness of typing commands with a Q - as in New-QADUser instead of New-ADUser or New-User - is something we will have to live with, until AD is PowerShell-enabled.

Kudos to the folks at Quest for making these available for free.

Also take a look at PowerShell Community Extensions - it has an Active Directory provider that lets you navigate AD like a file system.

If you already have a user created, you can use the Set-User command to populate its AD-related attributes.

To accomplish what we want to do here (thanks to Evan Dodds for the input), we use the New-Mailbox command, and pipe the output to Set-User to populate AD attributes. In the following example, we add the Phone attribute, besides using the Alias, Name and UserPrincipalName attributes used to create the mailbox.

Add the Phone column in our CSV/spreadsheet, so it looks like the following:

Alias,Name,UPN,Phone
User_One,User One,userone@yourUPNsuffix.com,650.555.1121
User_Two,User Two,usertwo@yourUPNsuffix.com,650.656,2221
User_Three,User Three,userthree@yourUPNsuffix.com,650.797.3321

Now we modify the script/commands from the previous post:

$password=Read-Host "Enter Password" -AsSecureString

Import-CSV "c:\CreateRecipients.csv" foreach {new-mailbox -alias $_.alias -name $_.name -UserPrincipalName $_.UPN -database "Mailbox Database" -org "Users" -Password $password | set-user -phone $_.phone}

The above command(s) create the user account as part of New-Mailbox. When we pipe that to Set-User, we still have a reference to that object, and can use Set-User to populate the AD attribute Phone. (Changes made to the command from previous post highlighted.)

Related Posts:
- Exchange Server 2007: Bulk creation of mailboxes using Exchange Management Shell
- Exchange Server 2007: Bulk mailbox-enabling users using Exchange Shell

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.

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?

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.

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?

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.

Released: Exchange Server 2007 Update Rollup 5

Exchange Server 2007 Update Rollup 5 is now publicly available.

Description of the rollup can be found in KB 941421.

In addition to all the fixes included in Update Rollups 1 thru 4 (remember, the Exchange Server 2007 patching model? All updates are cumulative.), this new rollup includes 2 additional fixes:

- Recipient email addresses contain "%40" instead of the @ sign (KB 940051)
- In meeting invitations sent by Notes users, non-English characters are replaced by question marks (KB 940058)

Managed Folders: How to apply different Managed Content Settings to Default Folders

Exchange Server 2007's Managed Folders come in two flavors: 1) Managed Default Folders 2) Managed Custom Folders. Default folders are the ones created by default in user mailboxes, such as Inbox, Sent Items, and Deleted Items. Custom Folders are the result of a much-requested feature by Exchange folks over the years: Can I create a folder called "Project Blah" in all mailboxes?

Exchange setup creates a set of default folders of each type e.g. Deleted Items. These are visible in Organization Configuration | Mailbox | Managed Default Folders tab, or by using the Get-ManagedFolder cmdlet.


Figure 1: Exchange setup creates a set of managed default folders of each type.

To apply message retention settings for items in a managed folder, you must create Managed Content Settings for it. For example, you can create a Managed Content Setting to retain items in the Deleted Items folder for 30 days, and permanently delete items older than 30 days.


Figure 2: You can create additional Managed Default Folders of type Deleted Items.

Next, you want to create another setting for your executives with a higher retention period of 300 days for the Deleted Items folder. If you try to create another Managed Content Settings for the same Default Managed Folder, you get the following error.


Figure 3: You cannot create an additional Managed Content Settings for the same message class for the same folder.

Managed Folders and Managed Content Settings

If Exchange only allows you to associate one Managed Content Settings with one Managed Folder, I've often wondered, why not allow specifying content retention settings in the Properties of that folder? Why have a Managed Folder AND a Managed Content Settings for that folder as separate objects?

This is to allow different Managed Content Settings for different types of items in a Managed Folder. For example, for the Deleted Items folder, you can create a Managed Content Setting to permanently delete messages after 30 days, but retain other types of items like faxes or Contacts for a little longer, let's say 60 days.

Note: You cannot change the Message Type selected in Managed Content Settings after it is created. To select a different Message Type, delete the Managed Content Settings object and recreate it with the correct/intended Message Type selected.

Create another Managed Default Folder
To create a new Managed Content Settings for a default folder, Deleted Items in this case, we need to create another default folder.

1. In the Exchange console, select Organization Configuration | Mailbox | Managed Default Folders.
   
2. In the Action pane, click the New Managed Default Folder link.
   
3. In the New Managed Default Folder page, enter a name for the new default folder instance. Note, unlike Managed Custom Folders, the default folders like Deleted Items, Inbox, Sent Items, Drafts, etc. already exist in a mailbox. What we're doing here is simply creating an instance/representation of a default folder, to be able to associate Managed Content Settings with it.
   
   
   Figure 4: Creating a new Managed Default Folder of type Deleted Items.
   
   
4. From the Default Folder Type drop-down, select the correct default folder type - for this example we select Deleted Items.
   
5. [Optional] Type a comment in the text box titled Display the following comment when the folder is viewed in Outlook. The comment will be displayed in Outlook 2007 when the user selects this folder.
   
6. Click New | click Finish on the Completion page.

Now you have another instance of the Deleted Items folder. You can create Managed Content Settings for it, and add it to a Managed Folder Mailbox Policy.


Figure 6: Another instance of the Deleted Items default folder.

For more information on applying Managed Folder Mailbox Policy, read previous post "Applying Managed Folder Policy to more than one user".

Related posts:
- Applying Managed Folder Policy to more than one user
- Exchange Server 2007: Why aren't Managed Content Settngs applied?
- Restricting Messaging Records Management to a particular message type

Exchange Server 2007: How to get a list of Exchange ActiveSync users

Getting a list of actual Exchange ActiveSync (EAS) users was not an easy task with Exchange Server 2003, and certainly not one that could be accomplished in a hurry.

Yes, it indeed is a one-liner shell command with Exchange Server 2007:

Get-CASMailbox | where {$_.HasActiveSyncDevicePartnership} | select Name

10/7/2008:
Here's an updated version, which uses the -Filter parameter to filter recipients on the server-side:

Get-CASMailbox -Filter {HasActiveSyncDevicePartnership -eq $true} | Select Name

Related posts and links:

• Exchange Server 2007: Listing Exchange ActiveSync users and device information
  
• Exchange 2003 - Active Sync reporting
  
• More on Exchange ActiveSync Reporting with Log Parser - COM object available
  
• Exchange ActiveSync, ISA 2006 and Error 0x85010004
  
• Exchange Server 2007 SP1: Take control of your Windows Mobile devices
  

Exchange Server 2007: Setting Message Size Limits

In a previous post, we looked at how the maximum recipients per message settings are treated differently by Exchange Server 2007 and Exchange Server 2003/2000 when sending to Distribution Groups (read previous post "Distribution Groups and maximum recipients per message").

Another commonly asked question is about message size limits and the inability to send messages that are apparently within the maximum sizes configured. Let's take a look at the message size settings in different places.

Organizational limits: These apply to all Exchange servers in the Organization. You can set these using the Set-TransportConfig command from the Exchange shell:

Set-TransportConfig -MaxReceiveSize 40MB -MaxSendSize 40MB

In SP1, you can also set it using the Exchange console by going to Organization Configuration | Hub Transport | Global Settings tab | Transport Settings | properties.

Receive Connector limit: Unlike Exchange SMTP Virtual Servers in Exchange Server 2003/2000, Exchange 2007's Receive Connectors are only used to receive messages. The maximum message size limit can be different on different Receive Connectors on a Hub Transport or Edge Transport server. To modify the maximum message size on a Receive Connector using the Exchange console, select Server Configuration | Hub Transport | select a HT server | Receive Connectors -> select a connector | Properties | General tab.



To set ReceiveConnector limit using the shell:

Set-ReceiveConnector "CONNECTOR NAME" -MaxMessageSize 40Mb

Send Connector limit: Send Connectors are used for sending outbound messages to the internet or particular address spaces (domains). Edge Transport servers also have a Send Connector to send inbound messages to Hub Transport servers in an AD Site. To modify the maximum message size on Send Connectors, select Organization Configuration | Hub Transport | Send Connectors -> select connector | Properties | General tab.



To set SendConnector limit using the shell:

Set-SendConnector "CONNECTOR NAME" -MaxMessageSize 40Mb

Mailbox limit: Individual recipients like mailboxes can have their own limits to bypass the Organizational limits. To set these using the Exchange console: Recipients | Mailbox -> select mailbox | properties | Mail Flow Settings tab | Message Size Restrictions.

Do individual size limits bypass the Organization size limit?

Setting higher message size limits on an Exchange recipient bypasses the maximum message sizes in the Exchange Organization configuration, albeit only for internal messages, not for messages sent to or received from unauthenticated sources.

Troubleshooting Sender and Recipient Size Limits: Consider the sender's MaxSendSize and the internal recipient's MaxReceiveSize when troubleshooting message size issues.

If the sender's size limits allow sending a large message, but the recipient's limits do not allow receiving a message of that size, you get a NDR with the following text (note the enhanced status code informing you exactly why the message was rejected):
#550 5.2.3 RESOLVER.RST.RecipSizeLimit; message too large for this recipient ##

If the recipient is allowed to receive a large message, but the sender isn't allowed to send a message of that size, you get the following NDR:
#550 5.2.3 RESOLVER.RST.SendSizeLimit; message too large for this sender ##

To set these using the Exchange shell:

Set-Mailbox "Joe Adams" -MaxSendSize 20Mb -MaxReceiveSize 20Mb

Distribution Groups and Contacts (MailContacts) only have maximum receive size in the Exchange console, but both MaxReceiveSize and MaxSendSize properties can be set for them using the Exchange shell.

Global Settings: Besides the above, another set of message size limits can impact Exchange Server 2007 recipients, but it's often overlooked when troubleshooting. This is the one in Exchange Server 2003 Global Settings | Message Delivery -> Properties.




- If you have these configured to a specific value before you upgrade the Organization to Exchange Server 2007, these are left untouched.
- If you have these set to "No Limit" before the Exchange Server 2007 upgrade, these are reset to the Exchange Server 2007 defaults.
- In case Exchange Server 2007's Organization settings (the ones you can set using Set-TransportConfig) conflict with these legacy Global Settings, the lower of the two sizes are used.

The problem is, these are neither visible in the EMC, nor using any of the Exchange shell commands.

If you still have an Exchange Server 2003 server in the Organization, you can use ESM to modify these limits. Alternatively, you can use ADSIEdit to browse to the Configuration container | Services | Microsoft Exchange | YourOrgName | Global Settings | Message Delivery -> Properties, and modify the following attributes as required:
1. delivContentLength -> corresponds to MaxReceiveSize parameter in Set-TransportConfig command.
2. SubmissionContentLength -> corresponds to MaxSendSize parameter in Set-TransportConfig command.
Note: The maximum value for both of the above is 2097151 KB, slightly under 2 Gb.
3. msExchRecipLimit -> corresponds to MaxRecipientEnvelopeLimit parameter in Set-TransportConfig command.

Set these to be the same as the equivalent Organization settings in Exchange Server 2007.

Exchange Server 2007 SP1 makes managing Global Settings easier.

If Global Settings have numeric values (i.e. aren't set to "No Limit"), using Set-TransportConfig to change maxReceiveSize, maxSendSize or maxRecipientEnvelopeLimit also changes the corresponding Global Settings.

Active Directory SiteLink limit: In Exchange Server 2007 SP1, you can also set maximum message size limit on AD Site Links. Exchange Server 2007 uses the AD Site topology to determine the least cost paths. If the message size to be delivered to a remote AD Site exceeds the limit on the AD Site Link, message delivery will fail. By default, the MaxMessageSize on AD Site Links is set to unlimited. This can be changed using the following command:

Set-ADSiteLink "SITE LINK NAME" -MaxMessageSize 20Mb

Routing Group Connector Limit: Routing Group Connectors are used in co-existence scenarios to transfer messages between Exchange Server 2003/2000 Routing Groups and the Exchange Server 2007 Routing Group (yes, there is one under the hood.. ). Messages exchanged between these Routing Groups should be below the message size limits of their respective RGCs. The default is set to unlimited. To set the MaxMessageSize on a Routing Group Connector:

Set-RoutingGroupConnector "CONNECTOR NAME" -MaxMessageSize 20Mb

Content conversion and message size limits

One source of confusion in previous versions of Exchange Server, as far as the message size limits are concerned, is that created by the content conversion process. Content conversion happens when Exchange converts an internet/MIME message into MAPI/Exchange format, and vice versa. Content conversion generally increases the message size - roughly by 30%. If you set a maximum message size of 10Mb., and wonder why a 9 Mb. attachment didn't make it through, consider the content conversion overhead, as also message headers (which are computed along with the DATA portion of the message to calculate the message size), and any actions taken by Transport Rules.

How does Exchange Server 2007 handle such messages? When a message enters the Exchange Server 2007 Org, it gets stamped with an X-MS-Exchange-Organization-OriginalSize header, which indicates the original size of the message before conversion. When considering message size limits, if the message has since ballooned to a larger size due to content conversion, added headers, etc. - the lower of the original message size and the current (converted) message size is considered, eliminating some of the confusion seen with message sizes in previous versions.

Using the Exchange shell to track failed message delivery

You can use the Exchange shell to track messages that could not be delivered because of message size issues. The RecipientStatus field in Message Tracking logs is used to store the SMTP response and enhanced status codes. The Message Tracking EventID we're looking for is FAIL. (Read previous post on message tracking: "Exchange Server 2007: Message Tracking from the command line")

To track messages that failed because of recipient's MaxReceiveSize:

Get-MessageTrackingLog -EventID FAIL | where {$_.RecipientStatus -like "*RecipSizeLimit*"}

To track messages that failed because of the sender's MaxSendSize:

Get-MessageTrackingLog -EventID FAIL | where {$_.RecipientStatus -like "*SendSizeLimit*"}

Distribution Groups and maximum recipients per message

In Exchange Server 2003, you can restrict maximum number of recipients per message in the following places:
1. Global Settngs (Message Delivery -> properties | Defaults)


Figure 1: Max recipients in Global Settings | Message Delivery -> properties | Defaults tab

2. SMTP Virtual Server -> properties | Messages
3. ADUC -> recipient -> properties | Exchange General tab | Delivery Options | Recipient Limits.

How does this work when sending to a Distribution Group?
In Exchange Server 2003, the max recipients restriction is enforced after the Categorizer has expanded Distribution Groups - a Distribution Group with 100 members is counted as 100 recipients. Distribution Group expansion stops when the maximum number of recipients is reached, resulting in a partial delivery.

This behavior has been changed in Exchange Server 2007 - the maximum recipients restriction is enforced before a Distribution Group is expanded. A Distribution Group is considered a single recipient, regardless of the number of members it has.

An interesting effect of the Exchange Server 2003 behavior in this regard: If a Distribution Group member has Delivery Restrictions set to receive from certain senders only, or to not receive messages sent by certain senders - the recipient is not counted in the total number of recipients post Distribution Group-expansion.

Consider this scenario:
- Maximum Recipients (in Global Settings): 100.
- Distribution Group members: 105
- No NDRs: Distribution Group is configured not to send Delivery Reports
- 5 members have Delivery Restrictions set to receive mail from certain senders only.
- Post-Categorization, the expanded number of recipients is 100, within the limits on Global Settings.
- No NDRs for recipient with Delivery Restrictions: If the Distribution Group is set to not send delivery reports (or to send them only to the group owner), you never find out about the recipient who did not get the message, because no NDRs are received.
- Turning on NDRs on the Distribution Group: If NDRs are turned on for the Distribution Group, you get the following NDRs for recipients with Delivery Restrictions

The following recipient(s) could not be reached:

George Foresman on 8/24/2007 2:52 PM
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<letter.exchangelabs.net>

- If Delivery Restrictions are removed from the recipients who had these configured, they are now counted in total number of recipients. Now you get a NDR with the following text:

The following recipient(s) could not be reached:

DL_Finance on 8/24/2007 2:49 PM
The e-mail system limits the number of recipients that can be addressed in a single message. Send the message multiple times to fewer recipients.
<letter.exchangelabs.net>

Lessons learnt:

• In Exchange Server 2003 the maximum number of recipients in Global Settings should be set higher than the maximum number of recipients in the largest Distribution Group.


• If you want to prevent certain senders from sending to large Distribution Groups like "All Company", you can configure max number of recipients per message for them individually in ADUC -> recipient properties.


• In Exchange Server 2007, Distribution Groups are considered a single recipient when enforcing max recipient limits, avoiding partial delivery.


• In either case, it's a good idea to limit who can send to large Distribution Groups by implementing Delivery Restrictions on such groups.


• Turning off Delivery Reports for Distribution Groups leaves senders and group owners completely unaware of incidents like members not getting messages due to a low max recipients setting or if some Distribution Group members have Delivery Restrictions. Use your judgment when turning off NDRs - it makes sense to at least send NDRs to group owners for all but the most trafficked Distribution Groups.
  

Released: Exchange Server 2007 Update Rollup 4

Microsoft has released another update to Exchange Server 2007 - Update Rollup 4. The roll-up is available for both platforms - x64 and x86.

This rollup fixes 9 issues, discussed in KB 940006.

The cumulative nature of Exchange Server 2007 updates/rollups means Update Rollup 4 includes the updates in Update Rollups 1, 2 & 3. [For more details on changes to the update/patch model for Exchange Server 2007, read the previous post, "Changes to hotfix/patching model for Exchange Server 2007"]

HOW TO: Create a new Storage Group in a CCR Cluster

Exchange Server 2007's Cluster Continuous Replication (CCR) clusters are not dependent on shared storage (when used with MNS quorum and a File Share Witness in Windows Server 2003). There are no protocol virtual server resources like SMTP, POP3, IMAP4, etc. — Exchange Server 2007's Clustered Mailbox Server (CMS) role is designed to be a Mailbox server. It cannot co-exist with any other Exchange 2007 server role.

This results in a greatly simplified cluster resource dependency model.

Note, Public Folder database support is available, with some limitations.

By default, the resources set up in a <CCR cluster:

• 1. IP Address
  
• 2. Network Name (depends on: IP Address resource)
  
• 3. Microsoft Exchange System Attendant (depends on: Network Name resource)
  
• 4. Microsoft Exchange Information Store (depends on: Network Name resource)
  
• 5. Microsoft Exchange Database Instance (depends on: Microsoft Exchange Information Store resource)

Notice, there are no shared disk resources in the above list!


Figure 1: Exchange Server 2007 resources in a CCR Cluster

This makes adding a new Storage Group to a CCR cluster easier. Generally you use a new set of volumes for the new Storage Group's transaction logs and mailbox Store, but there are no additional disk resources to add to the CMS in Cluster Administrator.

To add a new Storage Group:
1. In the Exchange console, create a new Storage Group
2. Add a new Mailbox Database to the Storage Group

That's it! Fire up cluster administrator and you'll see a new Microsoft Exchange Database Instance resource created for the new Storage Group, with the right dependencies.

Demo: CCR: Create New Storage Group

Use the following command in Exchange shell to verify the new Storage Group is being replicated to the passive node.

Get-StorageGroupCopyStatus "Second Storage Group" | Select SummaryCopyStatus,CCRTargetNode

HOW TO: Create a Dynamic Distribution Group by country or city

The Exchange console does not have pre-canned filter options for Country or City to be able to create a Dynamic Distribution Group (DDG, aka "Query-Based Distribution Group") for all recipients or mailboxes in a particular country or city. You can use options to filter on Department, Company, State or Province, or the custom/extension attributes 1-15.


Fig. 1: You can filter on Department, Company, State or Province or extension attributes 1-15 using pre-canned filters

If your Active Directory OUs are structured based on location (country/state/city), you can simply scope the DDG to that OU using the Exchange console, as shown in the following screenshot.


Fig. 2: You can set the scope of the DDG to a particular OU or container. Click here to see the complete dialog box.

However, if that's not the case (e.g. OU structure is based on business units or departments, etc.), you will need to use the Exchange shell to create a DDG with a custom filter.

To create a DDG for all user mailboxes from a particular country:

New-DynamicDistributionGroup -Name "US-Users" -OrganizationalUnit "OUorContainerNameToCreateGroupIn" -RecipientContainer "yourdomain.com" -RecipientFilter {RecipientType -eq "UserMailbox" -and CountryOrRegion -eq "United States"}

You can change the RecipientType to include other types of recipients.

To view recipients/mailboxes returned by the RecipientFilter: "HOW TO: View membership of a Dynamic Distribution Group".

Similarly, to create a DDG for all user mailboxes from a particular city:

New-DynamicDistributionGroup -Name "SF-Users" -OrganizationalUnit "OUorContainerNameToCreateGroupIn" -RecipientContainer "yourdomain.com" -RecipientFilter {RecipientType -eq "UserMailbox" -and City -eq "San Francisco"}

Dynamic Distribution Group quirkiness in Exchange 2007

In "New Distribution Groups do not receive internet email by default", I wrote about Devin's observation that all new Distribution Groups created in Exchange Server 2007 do not receive internet/unauthenticated email by default.

Here's some more often overlooked Dynamic Distribution Group (DDG, aka "Query-Based Distribution Group" in Exchange/Windows Server 2003) quirkiness. When creating a new Dynamic Distribution Group using the Exchange shell, you need to specify the required OrganizationalUnit parameter. This tells Exchange which OU or Container the new group should be created in. The RecipientContainer parameter is optional. It sets the scope of the AD query for the Dynamic Distribution Group - only recipients from that OU or Container are returned (and thus get mail sent to that group).

If you do not specify the RecipientContainer parameter, the shell sets it to the same value as the OrganizationalUnit parameter. As a result, the query may not return any recipients at all, or may not return all the recipients you think it should.

The documentation for New-DynamicDistributionGroup does point this out:

If you do not specify a value for RecipientContainer, the default search filter is the location of the dynamic distribution group in Active Directory. This location is specified by using the OrganizationalUnit parameter.

Scenario: If you create all groups in an OU or container called Distribution Groups, which has no users (or recipients other than the groups), the query will not return any users at all because its scope is now set to the Distribution Groups OU or container!

To get the RecipientContainer and OrganizationalUnit parameters of a Dynamic Distribution Group:

Get-DynamicDistributionGroup "MyGroupName" | select Name,RecipientContainer,OrganizationalUnit

Previewing recipients returned by a DynamicDistributionGroup filter
There's no easy way to view "membership" (or rather, the recipients returned by the Dynamic Distribution Group's filter) for Dynamic Distribution Groups created using a custom filter. You cannot easily verify whether the group's picking up the right recipients. You can test by sending messages to the new group and requesting a Delivery Report. However, if no recipients are returned by the filter, the messages disappear into a black hole, never to be heard from again, with no NDRs.

"HOW TO: View membership of a Dynamic Distribution Group" shows how to preview recipients returned by the RecipientFilter.

Bottomline, and best-practice: It's a good idea to set the RecipientContainer property when creating new Dynamic Distribution Groups.

Update: You can use the Get-MessageTrackingLog cmdlet to parse Message Tracking logs and quickly determine the recipients returned upon expansion. The EXPAND event is logged when the Categorizer expands distribution groups.

Related posts and links

• Exchange Server 2007: Message Tracking from the command line
  

New Exchange Server 2007 mailbox stamped as legacy mailbox

If you use the Exchange Server 2003/2000 extensions to Active Directory Users & Computers (ADUC) console to create mailboxes residing on Exchange Server 2007 servers, these mailboxes get stamped as legacy mailboxes.

Exchange Server 2007 mailboxes should be created using the Exchange (2007) console or shell.

To remove the legacy tag from mailboxes created using ADUC, use the following command:

Set-Mailbox "John Doe" -ApplyMandatoryProperties

This is documented in KB 931747: A mailbox that is located on an Exchange Server 2007 server may be identified as a legacy mailbox in Exchange Server 2007.

To get a list of legacy mailboxes:

Get-Mailbox | where {$_.RecipientTypeDetails -eq "legacymailbox"}

Note, not all legacy mailboxes reside on Exchange Server 2007 servers, so it's not a good idea to use the ApplyMandatoryProperties command to all of these. Mailboxes residing on Exchange Server 2003/2000 servers are also legacy mailboxes, and you may see some mailboxes moved from Exchange Server 2003/2000 servers carry this tag as well.

Let's filter the above list of legacy mailboxes to only the ones located on Exchange 2007 servers:

Get-ExchangeServer | Where {$_.IsExchange2007OrLater} | Get-Mailbox | where {$_.RecipientTypeDetails -eq "legacymailbox"}

Apply mandatory properties:

Get-ExchangeServer | Where {$_.IsExchange2007OrLater} | Get-Mailbox | where {$_.RecipientTypeDetails -eq "legacymailbox"} | Set-Mailbox -ApplyMandatoryProperties

New Distribution Groups do not receive internet email by default

New Exchange Server 2007 Distribution Groups created using the Exchange shell or console do not receive internet mail (i.e. mail from unauthenticated senders) by default. Thanks to Exchange MVP Devin Ganger for pointing this out.


Figure 1: By default, new Distribution Groups created in Exchange Server 2007 are configured to receive mail only from authenticated senders.

To allow internet mail to a Distribution Group:

Set-DistributionGroup "Group Name" -RequireSenderAuthenticationEnabled $false

When creating a new Distribution Group using the console, the option for authentication is not exposed. However, when creating one using the shell using the New-DistributionGroup command, the above optional parameter -RequireSenderAuthenticationEnabled can be set to false.

SP1 fixes setup failure issue with Windows 2000 domains

Exchange Server 2007 Service Pack 1 fixes setup related issues where setup fails when you do not have any Windows Server 2003 SP1 Domain Controllers in other Domains in the Forest (i.e. one or more domains have only Windows 2000 DCs/GCs), or one or more domains are unreachable during setup. More on the team blog: "A setup prerequisite change in Exchange 2007 SP1".

HOW TO: Forward mail to a Public Folder

When trying to forward inbound mail for a recipient to a Public Folder using the Exchange console (Recipient ->Properties | Mail Flow Settings | Delivery Options | Forward to: ), the Recipient Picker GUI does not display mail-enabled Public Folders.

This can be done from the shell using the following command:

Set-Mailbox "Foo" -ForwardingAddress "TestPF@mydomain.com"

The above command forwards mail to the Public Folder, without delivering a copy to the original recipient. To have a copy delivered to the recipient and forward it to a Public Folder, set the DeliverToMailboxAndForward property to true:

Set-Mailbox "Foo" -ForwardingAddress "TestPF@mydomain.com" -DeliverToMailboxAndForward $true

Once this is done, Delivery Options in the console does display mail being forwarded to the Public Folder.



Note, you can post to a Public Folder from Microsoft Outlook, but it should be mail-enabled to get an email address and receive (internet/smtp) email. To mail-enable a Public Folder, use the following command:

Enable-MailPublicFolder "\TestPF"

To find out how to add/remove email addresses and change the default email address for a public folder, read previous post "HOW TO: Add Email Addresses To Public Folders".

Move mailbox issue: disconnected mailbox remains on source mailbox Store

This came up earlier today in a newsgroup post. You move a mailbox from one mailbox Store to a mailbox Store on another server - either between two Exchange Server 2003/2000 servers, or between an Exchange Server 2003/2000 and an Exchange Server 2007 server. The mailbox moves successfully, the user can access it on the server it is moved to.

However, the mailbox is not purged from the source mailbox Store. It has a small size, and Exchange System Manager reports the number of items as 0. The mailbox is disconnected - it has a red x icon super-imposed, but ESM does not allow you to purge it or connect it to another user.

Running the mailbox cleanup agent on the Store does not change anything.

To be able to purge the mailbox from the target Store, try to move the mailbox back to that (original) Store. Move Mailbox will notify you that the mailbox already exists on the destination Store, and prompt you to purge it. Choose the option to purge.


The hotfix mentioned in KBA 940012 resolves this issue.

Exchange MVP Q&A chat transcripts posted to TechNet

Last month Microsoft held TechNet Exchange and Security MVP Q&As (chats). The transcripts are now available on the TechNet web site.

• Q&A with the Exchange MVP Experts (June 19, 2007) transcript


• Q&A with the Exchange MVP Experts (June 21, 2007) transcript


• Q&A with the Security MVP Experts (June 21, 2007) transcript

HOW TO: Prevent a user from sending and receiving internet mail

An often heard requirement is that of preventing one or a few users from sending/receiving internet mail.

Outbound internet mail: On Exchange Server 2003/2000, this was accomplished using Delivery Restrictions on SMTP Connector(s) for address space *.

Exchange Server 2007 doesn't have a similar way of implementing Delivery Restrictions, but it provides the convenience of inspecting messages in the transport pipeline and taking actions on those, using Transport Rules. To create a Transport Rule to prevent users from receiving internet mail:

Create a Distribution Group - let's call it "DG-NoInternetMail". Add the recipients you want to prevent from sending internet email as members of the group.

Create a Transport Rule [Flash demo]
1) Fire up Exchange console | Organization Configuration | Hub Transport | Transport Rules tab | click New Transport Rule
2) Enter a name for the rule - e.g. Rule-NoInternetMail
3) On the Conditions page, select "From a member of a distribution list"
4) In the rule description, click the link for distribution list (underlined)
5) Click Add | Select the distribution list "DG-NoInternetMail"
6) Under Conditions, select a second condition "Sent to users inside or outside the organization"
7) In the rule description, click Inside (underlined) | change scope to Outside
8) Click Next
9) On the Actions page, select "send bounce message to sender with enhanced status code"
10) If you want to modify the text of the bounced message (optional): In the description, click "Delivery not authorized, message refused" | enter new message text
11) Click Next | verify the rule conditions and action in the summary
12) Click New | click Finish

Inbound internet mail: In Exchange Server 2003/2000, you can prevent a recipient from receiving internet mail by requiring authentication to be able to send to the recipient. Internet senders are not authenticated. There are other ways to prevent inbound mail for certain users - like using Recipient Filtering, or generating an invalid email address from a non-existent domain, e.g. foo@nonexistentdomain.corp.

Exchange Server 2007 recipients can be set up to require sender authentication to receive email.

Using the Exchange console:
- Recipient Configuration -> select recipient -> recipient properties | Mail Flow Settings tab | Message Delivery Restrictions | Properties
- check "require that senders are authenticated"

Using the shell:

Set-Mailbox "Foo User" -RequireSenderAuthenticationEnabled $true

Additionally, either of the other 2 alternatives mentioned above for Exchange Server 2003/2000 can be used to prevent users from receiving internet email.

Setting delivery restriction based on group membership: Rather than setting up each recipient to receive inbound mail from authenticated senders only, you can get membership of the above distribution group and pipe it into the Set-Mailbox command:

Get-DistributionGroupMember "DG-NoInternetMail" | Set-Mailbox -RequireSenderAuthenticationEnabled $true

Use OWA/Outlook to test sending internet mail from a user who is a member of the distribution group.

Why Get-TransportAgent doesn't agree with the Exchange console

You disable a particular anti-spam agent - let's say the Content Filtering Agent - from the Exchange console.



Next, you use the Get-TransportAgent command to get the status of transport agents - and surprisingly the Content Filter Agent shows up as Enabled!



Why doesn't Get-TransportAgent agree with the Exchange console about the status of an agent?

Fellow MCT and Exchange geek David Elfassy blogged about it recently.

The Anti-Spam tab is located under the Organization Configuration | Hub Transport node in the console. Disabling an agent from the console prevents the agent on all transport servers in the Organization from taking any action. It's an Organization-wide or global setting.

The Get-TransportAgent command is transport server-specific. It shows the status of agents on a particular server. With the Org-wide configuration set to disabled, an agent enabled on a particular transport server behaves like a soldier instructed to fire but not kill. (May not be the best analogy - it doesn't exactly scare spam, and it doesn't do much else).

To draw a parallel to Exchange Server 2003, you can enable settings on a particular filter - e.g. Recipient Filtering, in Global Settings. However, you still have the flexibility of being able to enable/disable it on a per-SMTP virtual server basis. This is somewhat similar.

To get the global/Org-wide status of a particular filter, you need to use the corresponding command for that filter.
- For Content Filter Agent: Get-ContentFilterConfig
- For Recipient Filter Agent: Get-RecipientFilterConfig
- For Sender Filter Agent: Get-SenderFilterConfig
- For SenderID Agent: Get-SenderIDConfig
- For Protocol Analysis Agent: Get-SenderReputationConfig

If you've carefully looked at the above list, you're probably wondering why there's no mention of Connection Filtering Agent in it. The Connection Filtering Agent handles multiple tasks which are listed individually in the console.

To check the global setting for configuration of each, use the corresponding config command:
- For IP Block List: Get-IPBlockListConfig
- For IP Block List Providers: Get-IPBlockListProvidersConfig
- For IP Allow List: Get-IPAllowListConfig
- For IP Allow List Providers: Get-IPAllowListProvidersConfig

To "disable" an agent in Organization Configuration (equivalent of what you do in the console) using the shell, use the corresponding Set command, e.g.:

Set-ContentFilterConfig -Enabled $false

Next, let's take a look at how you can disable an agent on a transport server. Generally, if the Get-Blah command returns a property like Enabled: True, you can use Set-Blah -Enabled $false to disable it (You probably know where we're going with this by now... :). Not so for Get-TransportAgent. Its "Set" counter-part - Set-TransportAgent allows you to modify only one property -Priority. You can change the order in which these agents fire by changing their Priority.

You use the Disable-TransportAgent command to disable an agent on a transport server:

Disable-TransportAgent "Connection Filtering Agent"

No points for guessing the command used to enable a transport agent - Enable-TransportAgent

Exchange Server 2007 Update Rollup 3 Released

Microsoft has released Update Rollup 3 for Exchange Server 2007 (KB935999). This update comes about 7 weeks after the previous one. It has fixes for 6 issues, mostly minor ones, listed in KBA 935999.

The update is available for both 64-bit (x64) and 32-bit (x86) systems.

The cumulative nature of Exchange Server 2007 updates/rollups means Update Rollup 3 includes the updates in Update Rollups 1 & 2. [For more details on changes to the update/patch model for Exchange Server 2007, read the previous post, "Changes to hotfix/patching model for Exchange Server 2007"]

HOW TO: Add Email Addresses To Public Folders

A previous post shows how to add an additional email address to a mailbox/recipient [read "HOW TO: Add additional email addresses to a recipient"]. How do we add email addresses to Public Folders?

It should be pretty simple - If Get-Mailbox shows the emailaddresses property for a mailbox, and Set-Mailbox allows you to use the -EmailAddresses switch to add email addresses, one can't be blamed for believing it'll work the same way for Public Folders.

Objects other than Public Folders need to be mailbox or mail-enabled to be Exchange recipients, Public Folders do not (Yes, they are mail-enabled by default). To modify mail-related attributes of Public Folders, you use the Set-MailPublicFolder command.

To add additional email address to a (mail-enabled) Public Folder:

$PF = Get-MailPublicFolder "Sales"
$PF.EmailAddresses += "Sales-EMEA@domain.com"
$PF | Set-MailPublicFolder

The first line gets mail-related properties of Public Folder "Sales" in a variable called $PF. Next, we add the additional email address, without wiping out the existing ones. Finally, we commit the change using Set-MailPublicFolder.

If you simply use Set-MailPublicFolder "Sales" -EmailAddresses "Sales-EMEA@domain.com", it will replace the existing values in the EmailAddresses property.

Another difference to note between how the Set-PublicFolder and Get-PublicFolder commands work, compared to Set-MailPublicFolder and Get-MailPublicFolder - the former takes a relative path of a Public Folder. For instance, to get the Sales PF if it's in the root of the Public Folder tree, we would need to add a \ before the name:

Get-PublicFolder \Sales

However, the Get/Set-MailPublicFolder commands work using the alias/display name of the PF. Why the difference? One way to look at it - when using Get/Set-PublicFolder, you're working with the actual Public Folder. When using Get/Set-MailPublicFolder, you're working with the Active Directory object created for that Public Folder (which holds mail-related attributes, making it possible for a Public Folder to be mail-enabled).

To change the primary email address of the Public Folder "Sales" from "Sales@domain.com" to the new address we just entered - "Sales-EMEA@domain.com":

Set-MailPublicFolder "Sales" -EmailAddressPolicyEnabled $false -PrimarySmtpAddress "Sales-EMEA@domain.com"

As you may have already figured out, we exempted the Public Folder from getting EmailAddressPolicies applied. In Exchange Server 2003/2000, you could change the default email address of a recipient, without unchecking the checkbox. Result: A few minutes after you completed the change, Recipient Policies would apply and change the primary email address back.

Exchange Server 2007 doesn't let you change the default email address without exempting the recipient from email address policies.

HOW TO: Grant Full Mailbox Access permission

Follow-up to previous post titled "HOW TO: Assign SendAs right using Exchange shell" - the ability to assign SendAs and ReceiveAs permissions is preserved in AD Users & Computers, but the ability to grant Full Mailbox Access permission isn't available. Full Mailbox Access is a mailbox permission (without getting into a debate about what's a permission and what's a right, the term is used interchangeably here). In Exchange Server 2003/2000, mailbox permissions can be controlled from the Exchange Advanced tab | Mailbox Rights, as seen in the following screenshot.


Figure 1: In Exchange Server 2003/2000, mailbox permissions can be managed from ADUC

Since Exchange Server 2007 does not use ADUC for recipient management, this can't be done using ADUC.

The shell is your friend when it comes to assigning Full Mailbox Access and other mailbox permissions. You can use the Add-MailboxPermission command from the shell to assign it.

In the following example, we assign Full Mailbox Access permission on Joe Adams' mailbox to another user (janea):

Add-MailboxPermission "Joe Adams" -AccessRights FullAccess -user "janea"

Besides FullAccess, the following mailbox permissions can be granted using Add-MailboxPermission: 1) SendAs 2) ExternalAccount 3) DeleteItem 4) ReadPermission 5) ChangePermission 6) ChangeOwner

Viewing permissions using Get-MailboxPermission

To view permissions on a mailbox, use the Get-MailboxPermission command:

Get-MailboxPermission "Joe Adams"

To view explicitly assigned permissions (i.e. permissions that are not inherited):

Get-MailboxPermission "Joe Adams" | where {$_.IsInherited -eq $false}

To view all security principals with Full Access permission on a mailbox:

Get-MailboxPermission "Joe Adams" | where {$_.AccessRights -like "*FullAccess*"}

Managing Full Mailbox Access using the EMC in Exchange Server 2007 SP1

Exchange Server 2007 SP1 adds management of Full Mailbox Access permission to the EMC.
1. From Recipient Configuration | Mailbox | select mailbox.
2. In the Action pane (or by right-clicking the mailbox), click Manage Full Mailbox Access...


Figure 2: Exchange Server 2007 SP1 allows management of Full Mailbox Access permission from the EMC

HOW TO: Create Address Lists for Equipment Mailboxes

Exchange Server 2007 lets you create room and equipment mailboxes. Having these designated as resource mailboxes - either room or equipment - has its advantages as these get setup for resource booking without having to go through the cumbersome process of logging into such mailboxes and configuring calendar settings for each so they can be booked as resources.

Whereas an "All Rooms" Address List is created by default, equipment mailboxes are not listed in it, and there's no separate Address List for equipment. (Thanks to the person who asked this question in this morning's Exchange Q&A chat on TechNet!)

Additional Address Lists can be created easily for such equipment mailboxes.

To create an "All Equipment" Address List, use the following command in Exchange shell:

New-AddressList -name "All Equipment" -RecipientFilter {RecipientType -eq "UserMailbox" -and RecipientTypeDetails -eq "EquipmentMailbox"}

To view the mailboxes that get picked up by the above filter, use the following commands:

$AllEquipment = Get-AddressList "All Equipment"
Get-Recipient -filter $AllEquipment.RecipientFilter

You can also create more granular Address Lists, for example one for all projectors.

For this example, we follow a naming convention for naming equipment mailboxes for projectors, so it has a particular string like PROJ. In this case, our mailboxes follow a naming convention that results in projector mailboxes names like EQP-PROJ-InFocus1. You are free to make your own naming convention choices, this is just an example. Now we can use the following command to create an "All Projectors" Address List:

New-AddressList "All Projectors" -RecipientFilter {RecipientType -eq "UserMailbox" -and "RecipientTypeDetails -eq "EquipmentMailbox" -and name -like "*PROJ*"}

Now we have separate Address Lists for equipment resources, and also one for all projectors. This allows users to easily locate these resources using Address Lists when scheduling meetings.

Exchange Server 2007 and Address Literals

RFC 2821 allows the use of a literal form of a recipient's address, which uses the destination system's IP address enclosed by square brackets in the domain part, as an alternative to a domain name. Commonly known as address literals, this form of addressing helps in delivery of mail to a recipient when the recipient's domain is facing DNS issues - such as when DNS servers are not available, or domain registration records point to invalid or old DNS server (as may happen temporarily when moving to different DNS servers and old information lives on in DNS caches... ).

In addition to the technical glitches with DNS, there will always be that odd case of human error, when someone responsible in your organization for domain registrations/renewals, and paying the bills, forgets to pay up for renewal. If it can happen to Microsoft (Hotmail lost the domain name hotmail.co.uk, which expired due to non-renewal), it can happen to any of us.

Exchange Server 2003 supports address literals [read previous post "Address Literals and Microsoft Exchange"]. A Recipient Policy rule can be created to generate literal addresses. This allows mail delivery to a recipient, without relying on or using DNS.

The usage scenario: A monitoring system/service like Zenprise, which monitors service availability for email, DNS, etc. detects unavailability of your external DNS servers/zones, or some inconsistency with DNS zones or records. This affects mail delivery to your domain(s) using your normal email address(es) - e.g. foo@yourdomain.com. In such cases, the monitoring system or service can send mail using the address literal - foo@[1.2.3.4] or notify postmaster@[1.2.3.4].

Exchange Server 2007 does not support address literals - you cannot create an AcceptedDomain and EmailAddressPolicy (together these are equivalent of Recipient Policies in Exchange Server 2003/2000) to generate literal addresses, nor does it support manually adding such addresses to a recipient. Microsoft has no plans of reintroducing it.

However, much as one would like to see these supported, Exchange Server 2007 cannot be accused of not being standards-compliant - address literals are neither a requirement, nor a recommendation according to RFC 2821. It allows the use of such addresses.

Displaying Client IP Address in Exchange System Manager

In Exchange Server 2003, Exchange System Manager's Logons view for a Mailbox Store (expand Storage Group | Mailbox Store | Logons) displays client logon-related details.

The default view displays 1. User name 2. Windows 2000 Account 3. Logon Time 4. Last Access Time 5. Client Version. It does not display the client IP address from which users are logged on.

To display the IP address, add the Client IP Address column:

1. Expand the mailbox store | right-click Logons | View | Add/Remove Columns



2. Add Client IP Address



Besides the Client IP Address and other defaults mentioned above, the following logon-related fields are available:
1. Adapter Speed
2. Client Mode (Cached or not)
3. Client Name
4. Code Page
5. Folder Ops
6. Full Mailbox Directory Name
7. Full User Directory Name
8. Host Address
9. Latency
10. Locale ID
11. MAC Address
12. Messaging Ops
13. Open Attachments
14. Open Folders
15. Open Messages
16. Other Ops
17. Progress Ops
18. RPC Calls Succeeded
19. Stream Ops
20. Table Ops
21. Total Ops
22. Transfer Ops

For the scripting geeks amongst us, these properties are exposed by the Exchange_Logon WMI class.