• 1. London, UK
  • 2. New York, NY
  • 3. Sydney, Australia
  • 4. Melbourne, Australia
  • 5. Paris, France
  • 6. Mumbai, India
  • 7. Moscow, Russia
  • 8. Bangalore, India
  • 9. San Francisco, CA
  • 10. Amsterdam, The Netherlands
Bharat Suneja

Tuesday, June 09, 2009

 

User Self-Service: Message Tracking from OWA

Posted by Bharat Suneja at 11:08 AM
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?

Labels: , ,

Wednesday, April 22, 2009

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.

Labels: , ,

Thursday, April 09, 2009

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).

Screenshot: Error installing SSL certificate on IIS 7
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.

Labels: , , ,

Wednesday, March 25, 2009

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:

Labels: , ,

Tuesday, March 24, 2009

 

Internet Explorer 8 and OWA: Where Are The Images?

Posted by Bharat Suneja at 10:49 AM
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:

Screenshot: An HTML message with missing images in Outlook Web Access
Figure 1: An HTML message rendered in OWA with missing images

Instead of this:

Screenshot: An HTML message with images in Outlook Web Access
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.

Screenshot: Internet Explorer 8 prompt when accessing insecure content over a secure session
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:

Screenshot: Internet Explorer 8 prompt when accessing insecure content over a secure session
Figure 5: The 'Security Information' prompt in Internet Explorer 7, prompting users about nonsecure items

Labels: , , ,

Friday, March 20, 2009

 

Released: PowerShell Snap-in For IIS 7

Posted by Bharat Suneja at 8:30 AM
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.

Labels: , , ,

Wednesday, March 18, 2009

 

Released: Exchange 2007 SP1 Update Roll-up 7

Posted by Bharat Suneja at 3:32 PM
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

Labels: ,

Thursday, February 19, 2009

 

Are Distribution Groups really being used?

Posted by Bharat Suneja at 8:00 AM
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?

Labels: , , ,

Monday, February 16, 2009

 

Applying Exchange 2007 SP1 Update Rollup 6

Posted by Bharat Suneja at 7:58 PM
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.

Screenshot: Erro 1053 when manually starting Exchange managed services
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: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?

Labels: ,

Tuesday, February 10, 2009

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

Labels: ,

Tuesday, February 03, 2009

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

Screenshot: Configuring retention period in Managed Content Settings
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..

Labels: , , , ,

Thursday, December 11, 2008

 

EHLO: DSNConversionMode and You

Posted by Bharat Suneja at 1:13 PM
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.

Labels: , ,

Tuesday, December 09, 2008

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.

Labels: , ,

Wednesday, November 26, 2008

 

SCRIPT: List Delegates With Send On Behalf Access

Posted by Bharat Suneja at 12:01 AM
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.


Labels: , , ,

Thursday, November 20, 2008

 

Released: Update Rollup 5 for Exchange 2007 SP1

Posted by Bharat Suneja at 10:00 PM
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

Labels: , , ,

Tuesday, November 04, 2008

 

Start Managed Folder Assistant for a single mailbox

Posted by Bharat Suneja at 10:33 AM
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

Labels: , , , ,

Wednesday, October 08, 2008

 

Update Rollup 4: The Right Thing To Do

Posted by Bharat Suneja at 6:30 AM
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.

Labels: , ,

Tuesday, October 07, 2008

 

Released: Update Rollup 4 for Exchange 2007 SP1

Posted by Bharat Suneja at 1:00 PM
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

Labels: , , ,

Monday, September 29, 2008

 

Disable Antispam agents on a Receive Connector

Posted by Bharat Suneja at 5:20 PM
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

Labels: , , , , ,

Friday, September 26, 2008

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.

Screenshot: OWA | Open Other Mailbox


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.

Labels: , , , ,

Tuesday, September 16, 2008

 

Configuring Deleted Item Retention

Posted by Bharat Suneja at 6:39 AM
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.

Screenshot: Deleted Item Retention settings on Mailbox Database
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
Screenshot: Storage Quotas property page

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:
Screenshot: Get-Mailbox output with all *Deleted* properties

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

Labels: , , ,

Thursday, September 11, 2008

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.

Labels: , ,

Wednesday, September 10, 2008

 

SCRIPT: Get Storage Group Backup Status

Posted by Bharat Suneja at 2:47 PM
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.

Screenshot: Output of Get-SGBackupStatus.ps1 script
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.

Labels: , , ,

Wednesday, September 03, 2008

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:

Labels: , , ,

 

HOW TO: Prevent annoying spam from your own domain

Posted by Bharat Suneja at 8:46 AM
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:

Labels: , , , ,

Tuesday, August 19, 2008

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

Labels: , ,

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

Labels:

Monday, August 18, 2008

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

Labels:

Tuesday, August 12, 2008

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).
You can also use the site to search for other Microsoft products and subscribe to the feeds.

Labels: , , ,

Tuesday, July 29, 2008

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?

Screenshot: Transport Server properties
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:

Labels: , , ,

Monday, July 28, 2008

 

PowerShell: Listing multi-valued attributes

Posted by Bharat Suneja at 12:27 PM
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.

Screenshot: Multi-valued attributes and PowerShell
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


Screenshot: Multi-valued attributes and PowerShell 2
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

Screenshot: Multi-valued attributes and PowerShell 3
Figure 3: Listing all values in RemoteIPRanges multi-valued attribute of a Receive Connector

Related posts:

Labels: , , ,

Thursday, July 24, 2008

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).

Screenshot: Store Logons
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. These can be retrieved easily using the Exchange shell.

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.

Screenshot: Mailboxes node in Exchange 2003 ESM
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"}

Labels: , , , ,

Tuesday, July 15, 2008

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.

Labels: , , , , ,

Tuesday, July 08, 2008

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

Labels: , , , ,

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

Labels: , ,

Monday, July 07, 2008

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.

Labels: , ,

 

Controlling OOFs per domain and per mailbox

Posted by Bharat Suneja at 9:49 AM
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



Labels: , , ,

Tuesday, July 01, 2008

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

Labels: ,

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.

Labels: , , ,

Tuesday, June 24, 2008

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

Labels: , , ,

Monday, June 23, 2008

 

Released: Transporter Suite v08.02.0053

Posted by Bharat Suneja at 7:44 AM
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.

Labels: , , ,

Friday, June 20, 2008

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.

Labels: , , , ,

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

Labels: , ,

Tuesday, June 17, 2008

 

Starting Task Manager in RDP or VM sessions

Posted by Bharat Suneja at 5:49 PM
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

Labels: , ,

Monday, June 16, 2008

 

Quick antispam report or status check?

Posted by Bharat Suneja at 8:06 AM
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

Labels: , , , ,

Wednesday, June 11, 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!

Labels: , , ,

Wednesday, June 04, 2008

 

Perfmon counters show up as numbers?

Posted by Bharat Suneja at 12:22 AM
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).

Labels: ,

Monday, June 02, 2008

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.

Labels: , ,

Tuesday, May 20, 2008

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.

Labels: , , , ,

Thursday, May 08, 2008

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"

Labels: , ,

Monday, May 05, 2008

 

HOW TO: Remove the Public Folder Store

Posted by Bharat Suneja at 11:22 AM
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.

1 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

2 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

3 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.

Labels: , ,

Tuesday, March 25, 2008

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

Labels: , , ,

Monday, March 17, 2008

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"

Labels: , , ,

Tuesday, March 11, 2008

 

Routing outbound mail using a particular IP address

Posted by Bharat Suneja at 11:35 AM
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.

Screenshot: SMTP Virtual Server properties - General tab
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.

Labels: , , ,

Monday, March 03, 2008

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)

1 Allow generic read permission for objects in the OU:

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

2 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".

3 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

4 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

5 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

6In 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"

Labels: , , , ,

Thursday, February 21, 2008

 

Released: Exchange Server 2007 Update Rollup 6

Posted by Bharat Suneja at 11:00 AM
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.

Labels: ,

Monday, February 18, 2008

 

How to forward mail to an external email address

Posted by Bharat Suneja at 9:52 PM
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.

1 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.

2 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
Screenshot: Delivery Options -< Forwarding Address
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.

Screenshot: Remote Domain properties
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.

Labels: , , ,

Monday, February 11, 2008

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

Labels: , , ,

Sunday, February 10, 2008

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

Labels: , ,

Monday, January 28, 2008

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.

1 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

1 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).

1 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

Labels: , , , , ,

Wednesday, January 23, 2008

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.

1 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
Using a Transport Rule to inspect message headers
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)

2 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.

Labels: , , ,

Wednesday, January 09, 2008

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)

Screensot: Content Restrictions on Exchange Server 2003/2000 SMTP Connectors
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

Labels: , , ,

Thursday, January 03, 2008

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.

Modifying an existing Recipient Policy

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

Modifying property pages in a 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

Labels: , ,

Tuesday, December 18, 2007

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.

Changing fqdn in SMTP VS properties
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.

ExBPA error: Missing Service Principal Name
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

Labels: ,

Monday, December 17, 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.

Labels: , , , ,

Friday, December 14, 2007

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.

Boston RedSox logoThe 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".

Labels: , , ,

Wednesday, December 05, 2007

 

Disabled mailboxes: Can they really receive email?

Posted by Bharat Suneja at 5:47 PM
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:

Delivery Restrictions dialog box in Exchange General tab
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).

Labels: , ,

Tuesday, December 04, 2007

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

Labels: , , , , ,

Thursday, November 29, 2007

 

Released: ForeFront Security for Exchange SP1

Posted by Bharat Suneja at 7:15 PM
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.

Labels: , , , ,

Wednesday, November 28, 2007

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?

Labels: , , ,

Tuesday, November 20, 2007

 

Exchange Server 2007: How many logs hath thee?

Posted by Bharat Suneja at 6:00 PM
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.

The EMC allows you to enable/disable common transport server logs
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.

Table1: Exchange Server 2007 logs with default locations

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.

Labels: ,

Wednesday, November 07, 2007

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.

Screenshot: Expired message in custom folder
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.