The Fix is In! For the Exchange 2007 provisioning issue with ILM 2007 anyway…

Microsoft released the fix for the Exchange 2007 provisioning issue I blogged about earlier.  Essentially, Exchange didn’t properly use the domain controller parameter that was to the Update-recipient cmdlet, which in environments with multiple DCs would result in the mailbox not being properly provisioned because the DC in use by Update-Recipient didn’t know anything about the mailbox, as it was created on another DC.

Anyway, after a long wait (and a teaser release/un-release), Update Rollup 4 for Exchange Server 2007 SP1 has been re-released and contains the fix.  The KB article (949858) behind the specific issue is also public now.  Here are the details on the issue from the KB:

When ILM 2007 calls the Update-Recipient cmdlet to provision user objects, ILM 2007 passes a domain controller parameter to the Update-Recipient cmdlet to make sure that the task uses the same domain controller as the domain controller that was used where the object was created.

However, the Update-Recipient cmdlet creates two domain controller sessions. One session is for a domain controller, and the other session is for a global catalog server. The Update-Recipient cmdlet uses only the parameter that was passed for the global catalog server session, and it enables the Active Directory directory service driver to obtain a domain controller for the domain controller session. Then, the domain controller session is used for various operations, such as retrieving the properties of the object to pass to the Recipient Update Service.

If the domain controller that is selected for the domain controller session differs from the domain controller that is passed by ILM 2007, the Recipient Update Service object may not find the recipient. This issue occurs because of replication latency.

When this issue occurs, user objects may not be updated correctly by the Update-Recipient cmdlet. These objects are displayed as "mail users" instead of as "user mailboxes" in Exchange Management Console.

You can download Update Rollup 4 for Exchange Server 2007 SP1 here.

Exchange 2007 Provisioning Issue with ILM 2007 FP1

I've been meaning to post on this for a while, but have been pretty busy.

A few months ago I did a project which included Exchange 2007 provisioning with ILM. When running a small development environment (single DC, very important), everything ran fine. But when it got to production I noticed that when the new connector space object is exported to AD, the mailbox is a "Legacy Mailbox" in Exchange because it does not have all of the required Exchange 2007 attributes. I also noticed that when any type of update for that user is exported to the AD MA, the mailbox is then updated to be a standard Exchange 2007 mailbox. From Shawn's blog post, I learned the ILM code is simply using the Update-Recipient cmdlet under the covers to do the update. In Exchange 2003, the Recipient Update Service handled the stamping of the remaining Exchange specific object on the user object and completing the set up of the mailbox. In Exchange 2007, the RUS has been removed, so the Update-Recipient cmdlet was specifically added to address this type of situation. Update-Recipient is called by ILM every time there is an export for that object, and is supposed to use the same DC that the AD MA is using. Key word: supposed.

Turns out there is a bug in the Update-Recipient cmdlet. It does NOT consistently use the same DC as the MA, so while you are exporting your object to one DC, Update-Recipient goes off to another DC where the object does not exist yet. Best of all, when it does, it silently errors out.

After much poking around, I developed a suitable, fairly simple workaround - trigger a second export for any provision action to AD. The workaround goes like this:

1. Extend the Metaverse schema to include an attribute for the AD SID (we'll call it ad_sid for this).
2. Create an inbound flow rule to place the user SID from your AD MA to the Metaverse ad_sid attribute.
3. Find a relatively insignificant attribute that flows from the Metaverse to all users in your AD MA (we'll use title for this).
4. Create an export flow rule using a Rules Extension to only flow the title attribute from the Metaverse to the AD MA if ad_sid is present in the Metaverse (you'll need to send both the title and ad_sid attributes to the AD MA title attribute).

Now, when a new user is provisioned into AD, a confirming import will bring the user's SID into the Metaverse. The user won't have a title, but the import of the SID will trigger the new export flow rule and generate a pending export of the title. Ensure a suitable amount of time passes to allow AD replication to occur so that the new user is present on all DCs, and then when this second change is exported, Update-Recipient will be called again. Regardless of what DC it uses, it will then be successful and the user will go from "Legacy Mailbox" to "Exchange Mailbox".

Here is a sample bit of code for the Export Flow Rule:

Select Case FlowRuleName
Case "set_cs.title"
If mventry("ad_sid").IsPresent Then
csentry("title").Value = mventry("title").Value
End If
Case else
Throw New EntryPointNotImplementedException()
End Select

In terms of a fix, it is important to remember this is actually an Exchange issue, not an ILM issue. For someone within MS I was able learn that supposedly the KB article behind this is KB949858, but it is not publicly released. The fix was initially slated for Exchange 2007 SP1 Rollup 3, but it didn't make it in and should in Rollup 4 - the release of which, I learned from Aaron's post today, is imminent. Looks there are some issues with the links to the download though; I imagine they will be straightened out shortly.

Two PowerShell Event Logs on Exchange 2007 Servers

When PowerShell 1.0 is installed an Event Log called "Windows PowerShell" is created.  When Exchange 2007 is then installed, a second Event Log called "PowerShell" is created.  When this log is created, multiple entries are added each time the Exchange Management Shell is opened, so this log rapidly fills up and you will get errors unless you go and change the configuration of the Event Log.  More interestingly, the entries in the "PowerShell" Event Log are unable to be resolved so that the description can be presented.  A typical entry in this log looks like this:

Event Type:      Information
Event Source:      PowerShell
Event Category:      (4)
Event ID:      403
Date:            5/12/2007
Time:            2:45:55 AM
User:            N/A
Computer:      MYCOMPUTER
Description:
The description for Event ID ( 403 ) in Source ( PowerShell ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Stopped, Available,       NewEngineState=Stopped
      PreviousEngineState=Available
      SequenceNumber=20
      HostName=Default MSH Host
      HostVersion=1.0.0.0
      HostId=2afe9b64-5601-4df3-8478-6efc5cf2c471
      EngineVersion=1.0.0.0
      RunspaceId=433e6992-c711-47a8-b732-728a45104767
      PipelineId=
      CommandName=
      CommandType=
      ScriptName=
      CommandPath=
      CommandLine=.

To resolve this issue, simply delete the following registry key, which will delete the "PowerShell" Event Log:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\PowerShell

A reboot is required for the change to take effect.  Once the "PowerShell" log is deleted and the server is rebooted, the PowerShell events will flow into the "Windows PowerShell" Event Log without issue, and you will be able to properly view the description of the events.

Note though, that updates or service packs for Exchange may put this Event Log back in, so check for it after any update and simply delete the registry key again if it appears.

Comparing Exchange 2007 UM and Cisco Unity UM

I've had many clients ask for a feature comparison between Exchange 2007 UM and Cisco Unity CM.  Until I stumbled across this blog posting from Matt McGillen, I had nothing tangible to offer.  Kudos to Matt for assembling this.

Relocating the Exchange 2007 Queue Database

Summary from the "How to Change the Location of the Queue Database" article in the Exchange Server TechCenter:

Microsoft Exchange Server 2007 uses an Extensible Storage Engine (ESE) database for queue message storage. Formerly known as JET, ESE is a method that defines a low-level API to the underlying database structures in Exchange Server. All the different queues are stored in a single ESE database. Queues exist only on servers that have the Hub Transport server role or the Edge Transport server role installed.

The location of the queue database is controlled by the QueueDatabasePath parameter in the EdgeTransport.exe.config application configuration file that is located in the C:\Program Files\Microsoft\Exchange Server\Bin directory. The location of the logs is controlled by the QueueDatabaseLoggingPath parameter in the same file.  The following list describes some important items to consider when you change the location of the queue database and logs:

• If the target directory doesn't exist, it will be created for you if the parent directory has the following permissions applied to it:
  • Network Service: Full Control
  • System: Full Control
  • Administrators: Full Control
• The existing queue database files Mail.que and Trn.chk are not moved. New queue database files are created at the new location after you save the EdgeTransport.exe.config application configuration file and restart the Microsoft Exchange Transport service. The existing database files are left at the old location. However, they are no longer used.
• The existing queue database transaction log files Trn.log, Trntmp.log, Trnnnn.log, Trnres00001.jrs, Trnres00002.jrs, and Temp.edb are not moved. New queue database transaction logs are created at the new location after you save the EdgeTransport.exe.config application configuration file and restart the Microsoft Exchange Transport service. The existing transaction log files are left at the old location. However, they are no longer used.
• If you want to change the location of the queue database but reuse the existing queue database files, you must move or copy the database files when the Microsoft Exchange Transport service is stopped.  The same goes for the logs.

The steps to move the database (and logs) are as follows:

• Create the target directory (or directories if you are moving the logs to a separate location)
• Edit the QueueDatabasePath parameter in the EdgeTransport.exe.config file to reflect the new database path
• Edit the QueueDatabaseLoggingPath parameter in the EdgeTransport.exe.config file to reflect the new database path
• Stop the Microsoft Exchange Transport service
• If preserving the old database (which you should because there is likely mail in there that has yet to be delivered), move the Mail.que and Trn.chk from the original location to the new location.
• If preserving the old logs (again, which you should) move the Trn.log, Trntmp.log, Trnnnnn.log, Trnres00001.jrs, Trnres00002.jrs, and Temp.edb files to the new location.
• Start the Microsoft Exchange Transport service

Granting "Send As" rights in Exchange 2007

Many times it is necessary to grant a service account the ability to open a users mailbox and/or send email as that user.  Products that tightly integrate with Exchange like Blackberry Enterprise Server (BES), Quest Archive Manager (QAM), and many others need this in order to function properly.  This is accomplished by granting the service account the "Full Mailbox Access" and "Send As" rights for all mailboxes in the organization (assuming the application in question is to be rolled out enterprise-wide).

For those that are unclear, it is critical to understand the difference between "Send As" and "Send on Behalf Of".  "Send As" allows a user to "impersonate" another user and send email as the other user.  For example, if User A is granted "Send As" rights to User B's mailbox, then User A is able to send messages directly as User B and means that the recipient of the message will think that User B has sent the message, even though it was actually User A that sent it.  The "Send As" right can only be done by an administrator; a user cannot grant the "Send As" right to another user.

"Send on Behalf Of" allows a user to send email from another user's mailbox, but the sending user is not impersonated.  For Example, if User A is granted "Send on Behalf Of" rights to User B's mailbox, then User A is able to send message from User B's mailbox and the recipient would receive a message that is from "User A on behalf of User B".  By looking at the "From" field in the email, it is always very clear who is sending the message.  Like "Send As", the "Send on Behalf Of" right can be granted by an administrator, but unlike "Send As", "Send on Behalf Of" can also be established by the end user.  Through the Outlook client, a user can grant another user the ability to send on behalf of them.

For more information on granting "Send As" in an Exchange 2003 environment, or granting "Send on Behalf Of" permissions, check out this tutorial from MSExchange.org.

Now back to the problem at hand...

"Full Mailbox Access" and "Send As" rights can be granted on a single mailbox (or batch of mailboxes) with the following PowerShell cmdlets (using User A and User B from the examples above):

Add-MailboxPermission UserB -AccessRights FullAccess -user UserA

Add-ADPermission UserB -ExtendedRights Send-As -user UserA

Note that granting "Full Mailbox Access" does not include the "Send As" permission; "Send As" must be explicitly granted.

The problem with this method is that even if the script is such that it will grant the appropriate rights on all mailboxes in the environment, this will not automatically grant the rights to the service account for new mailboxes and the script must be re-run on a regular basis.  For message archival applications in particular this is a problem as some data may be missed because the service account was unable to access the mailbox.  So you must use a method to grant the required permissions automatically.

A personally recommended best practice is to create a group that has the "Send As" rights in Exchange and add the appropriate user accounts to that group.  Because there is risk with any account that has these rights to your entire Exchange organization, those account must be as secure as possible and the membership of that group must be controlled and monitored tightly.

To grant the required permissions, follow these steps:

1. At the command prompt, type ADSIedit.msc. This requires the Windows Server 2003 Support Tools.
2. In the Action menu, select Connect to…
3. Select the Select a well known Naming Context radio button.
4. Select Configuration from the drop-down list.
5. The Default (Domain or server that you logged in to) radio
   button is selected. Leave this button selected if the machine you are
   logged in to is in the same domain as the Exchange 2007
   organization. If the machine you are logged in to is in a different
   domain, select Select or type a domain or server and enter the
   domain controller name.
6. Click OK to return to the ADSI Edit window.
7. Select the Configuration node that contains the name of the domain
   controller that holds your Exchange 2007 organization.
8. Navigate to CN=Services | CN = Microsoft Exchange |
   CN=”Your Exchange Organization”.
9. Right-click the organization node and select Properties.
10. Select the Security tab and click Advanced.
11. Click Add, and select the appropriate user or group.
12. In the Permission Entry window, ensure that Apply Onto is set to This object and all child objects.
13. Check the box for Full Control in the Allow column.
14. Click OK to add the entry, and click OK to exit the windows.
15. Close ADSIedit.

Be very sure that the accounts you use are not also in any groups which are denied "Send As" rights, or you will still be denied.  By default, the Domain Admins, Enterprise Admins, and Exchange Organization Administrators groups are denied "Send As" rights (and should be kept that way).

Exchange 2007 Autodiscover White Paper

Newly updated.

This white paper provides detailed information about the Microsoft Exchange Autodiscover service. It also includes information about how to configure this service in various deployment scenarios. Use the conceptual information and procedures in this white paper to help you deploy the Autodiscover service.

http://technet.microsoft.com/en-us/library/59adba4e-44e1-4aa2-b09d-06988cbeab2d.aspx

Exchange 2007 SP1 Documentation

The Exchange Team Blog has a nice post up with links to new and updated documentation on the changes in Exchange 2007 SP1 and how to deploy SP1 in your environment. Here is the listing:

• What's New in Exchange Server 2007 SP1
• Standby Continuous Replication
• Upgrading Clustered Mailbox Servers to Exchange 2007 SP1
• Monitoring Continuous Replication
• New High Availability Features in Exchange 2007 SP1
• How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008
• Installing Cluster Continuous Replication on Windows Server 2008
• Installing Single Copy Clusters on Windows Server 2008
• New Client Access Features in Exchange 2007 SP1
• New Transport Features in Exchange 2007 SP1
• New Mailbox Features in Exchange 2007 SP1
• New Unified Messaging Features in Exchange 2007 SP1
• IPv6 Support in Exchange 2007 SP1

Exchange Management Shell Quick Reference

Exchange 2007 introduces a new management platform called the Exchange Management Shell, based on Windows PowerShell, formerly codenamed "Monad". This quick reference guide provides a list of frequently used cmdlets, important conventions, and useful tips. The information is presented by feature area, such as recipient, transport, and database administration. This quick reference guide applies to Exchange 2007 SP1 and the RTM version of Exchange 2007.

http://www.microsoft.com/downloads/details.aspx?familyid=01a441b9-4099-4c0f-b8e0-0831d4a2ca86&displaylang=en&tm

ISA, Exchange 2007, and SAN Certificates

The ISA Server Product Team Blog has a great new post on the issues surrounding publishing sites with SSL certificates with Subject Alternative Names. Great information to consider for Exchange 2007/ISA designs…

http://blogs.technet.com/isablog/archive/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing.aspx

Exchange 2007 and the legacyExchangeDN

Jim McBee has a great post on his blog (complete with a Powershell script) for upgrading a mail-enabled user to a mailbox-enabled user and setting the old legacyExchangeDN as an X500 address. Leveraging the X500 address ensures that any old emails, nicknames, etc. still resolve to the correct user after the change.

Exchange 2007 Visio Stencils

This stencil and template provided enable you to create Visio drawings that contain Exchange Server 2007 objects. These shapes include icons for Exchange 2007 server roles, networking, telephony and Unified Messaging objects, Active Directory and directory service objects, client computers and devices, and other Exchange organization elements.

Get it here.

Outlook 2007 Autodiscover Whitepaper

Microsoft Office Outlook 2007 includes the ability to automatically configure user accounts. Outlook uses one of two discovery mechanisms to automatically configure accounts: Autodiscover and Common Settings Discover. This whitepaper describes how the discovery mechanisms work, and how an administrator can modify settings in an XML file to configure Autodiscover for an organization.

Outlook 2007 Autodiscover Whitepaper

How to Remove the Last Legacy Exchange Server from an Organization

Nothing earth shattering here, just something for my future reference...

Exchange Server 2007: How to Remove the Last Legacy Exchange Server from an Organization