A Collection of Random Thoughts

Recent experience with Exchange 2007 and Cross-Forest account management

Ben Winzenz [MSFT] — Tue, 02 Nov 2010 19:09:11 GMT

I wanted to share some lessons learned recently as a result of working a case where the goal was to create a new mail contact in a remote forest. Existing contacts were able to be edited, so permissions didn’t appear to be the issue. I was able to set up a cross-forest trust in my lab, and reproduced the problem. This problem really only exists in Exchange 2007, as Exchange 2010 supports opening a Remote Powershell instance where you could connect directly to the remote forest from a server in the source forest.

Here I am trying to create a new mail contact. I tried to keep the parameters I used pretty simple. By specifying the domain controller as a DC in the remote forest, I ensure that I am talking to that forest when I attempt to create the contact. I’ve highlighted a few things that stood out to me.

[PS] C:\WINDOWS\system32>New-MailContact -Name "Blah Test" -ExternalEmailAddress blahblah@blah.com -PrimarySmtpAddress blah@mydomain.com –DomainController <Remote Forest DC> -Verbose –OrganizationalUnit <Remote Forest OU>
VERBOSE: New-MailContact : Beginning processing.
VERBOSE: New-MailContact : Searching objects "<Remote Forest OU>" of type "ExchangeOrganizationalUnit" under the root "$null".
VERBOSE: New-MailContact : Previous operation run on domain controller <Remote ForestDC>.
VERBOSE: New-MailContact : Administrator Active Directory session settings are: View Entire Forest: 'False', Default Scope: ‘<Source Forest>’, Configuration Domain Controller: '<Source Forest DC>',
VERBOSE: New-MailContact : Applying RUS policy to the given recipient "<Remote Forest>/Contacts/Blah Test" with the home domain controller "<Remote Forest DC>".
VERBOSE: New-MailContact : The RUS server that will apply policies on the specified recipient is "<Remote Forest MBX server>".
VERBOSE: New-MailContact : Searching objects of type "ADRecipient" with filter "(&((!((Id Equal <Remote Forest>/Contacts/Blah Test)))(|((EmailAddresses Equal SMTP:blah@<Remote forest.com>)))))", scope "SubTree" under the root "$null".
VERBOSE: New-MailContact : Processing object "<Remote Forest>/Contacts/Blah Test".
VERBOSE: Creating Mail Contact "Blah Test" with External E-mail Address "SMTP:blahblah@blah.com", Organizational Unit "<Remote Forest>/contacts".
VERBOSE: New-MailContact : The properties changed are: "{ DisplayName='Blah Test', AddressListMembership={ '\Default Global Address List' }, Alias='BlahTest', EmailAddresses={ 'SMTP:blah@<remote forest.com>' }, RawExternalEmailAddress='SMTP:blahblah@blah.com', PoliciesExcluded={ '{26491cfc-9e50-4857-861b-0cb8df22b5d7}' }, Id=’<Remote Forest>/Contacts/Blah Test', RawName='Blah Test', ObjectCategory='<Source Forest>/Configuration/Schema/person' }".
VERBOSE: New-MailContact : Saving object "<Remote Forest>/Contacts/Blah Test" of type "ADContact" and state "New".
VERBOSE: New-MailContact : Previous operation run on domain controller ‘<Remote Forest DC>’. New-MailContact : Active Directory operation failed on <Remote Forest DC>. This error could have been caused by user input or by the Active Directory server being unavailable. Please retry at a later time. Additional information: Additional information: The global catalog verification failed. The global catalog is not available or does not support the operation. Some part of the directory is currently not available. Active directory response: 000020E1: SvcErr: DSID-032005F2, problem 5002 (UNAVAILABLE), data 0. At line:1 char:16 + New-MailContact <<<< -Name "Blah Test" -ExternalEmailAddress blahblah@blah.com -PrimarySmtpAddress blah@<RemoteForest.com> –DomainController <Remote Forest DC> -Verbose –OrganizationalUnit <Remote Forest>/contacts
VERBOSE: New-MailContact : Ending processing.

I was capturing a Netmon trace during this after disabling LDAP encryption (see , and this was the frame that showed the LDAP add request (creating the mail contact). Note the highlighted part below.

Frame: Number = 233, Captured Frame Length = 1035, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-41-BD-00],SourceAddress:[00-15-5D-41-BD-0B]
+ Ipv4: Src = 10.10.100.16, Dest = 10.10.0.200, Next Protocol = TCP, Packet ID = 13162, Total IP Length = 1021
+ Tcp: Flags=...AP..., SrcPort=33110, DstPort=LDAP(389), PayloadLen=981, Seq=1117411596 - 1117412577, Ack=4214889466, Win=64154
- Ldap: Add Request, MessageID: 119
+ SASLBuffer:
- Parser: Add Request, MessageID: 119
   + ParserHeader:
   + MessageID: 119
   + OperationHeader: Add Request, 8(0x8)
   - AddRequest: Entry: CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com
    - Entry: CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com
     + AsnOctetStringHeader:
       OctetStream: CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com
    - Attributes: 13 Partial Attributes
     + SequenceHeader:
     + PartialAttribute: CountryCode=( 0 )
     + PartialAttribute: displayName=( Blah Test )
     + PartialAttribute: showInAddressBook=( CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=<ORG Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<remote forest>,DC=com )
     + PartialAttribute: mailNickname=( BlahTest )
     + PartialAttribute: proxyAddresses=( SMTP:blah@<remote forest>.com )
     + PartialAttribute: targetAddress=( SMTP:blahblah@blah.com )
     + PartialAttribute: internetEncoding=( 1310720 )
     + PartialAttribute: msExchPoliciesExcluded=( {26491cfc-9e50-4857-861b-0cb8df22b5d7} )
     + PartialAttribute: msExchRecipientDisplayType=( 6 )
     + PartialAttribute: distinguishedName=( CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com )
     + PartialAttribute: msExchVersion=( 4535486012416 )
     + PartialAttribute: objectCategory=( CN=person,CN=Schema,CN=Configuration,DC=<source forest>,DC=com )

In response to this, I got the LDAP error seen in the Powershell window.

LDAP:Add Response, MessageID: 119, Status: Unavailable ErrorMessage: 000020E1: SvcErr: DSID-032005F2, problem 5002 (UNAVAILABLE), data 0

If you see the same thing I did (well, since I’ve been nice and highlighted it), you probably know why the operation failed. Yes indeed, the LDAP Add request is passing an attribute value that contains the source forest. No wonder why the remote domain controller was responding with an error!

Luckily, Powershell allows you to control some additional settings via $AdminSessionADSettings. Checking the current settings, I found the following listed

[PS] C:\WINDOWS\system32>$adminsessionadsettings
ViewEntireForest              : False
DefaultScope                  : <source domain>
PreferredGlobalCatalog        :
ConfigurationDomainController : <souce domain DC>
PreferredDomainControllers    : {}

On a whim, I changed the config DC to point to one in the remote forest by running the cmd

$adminsessionadsettings.configurationdomaincontroller = ‘<remote forest DC>’

[PS] C:\WINDOWS\system32>$adminsessionadsettings
ViewEntireForest              : False
DefaultScope                  : <source domain>
PreferredGlobalCatalog        :
ConfigurationDomainController : <remote forest DC>
PreferredDomainControllers    : {}

After making this change, I ran the cmdlet once again, expecting it to fail, but it succeeded.

[PS] C:\WINDOWS\system32>New-MailContact -Name "Blah Test" -ExternalEmailAddress blahblah@blah.com -PrimarySmtpAddress blah@mydomain.com –DomainController <remote forest DC> -Verbose –OrganizationalUnit <remote forest OU>
VERBOSE: New-MailContact : Beginning processing.
VERBOSE: New-MailContact : Searching objects "<remote forest OU>" of type "ExchangeOrganizationalUnit" under the root "$null".
VERBOSE: New-MailContact : Previous operation run on domain controller '<remote forest DC>'.
VERBOSE: New-MailContact : Administrator Active Directory session settings are: View Entire Forest: 'False', Default Scope: '<source forest>', Configuration Domain Controller: '<remote forest DC>',
VERBOSE: New-MailContact : Applying RUS policy to the given recipient "<remote forest OU>/Blah Test" with the home domain controller "<remote forest DC>".
VERBOSE: New-MailContact : The RUS server that will apply policies on the specified recipient is "<remote forest MBX server>".
VERBOSE: New-MailContact : Searching objects of type "ADRecipient" with filter "(&((!((Id Equal <remote forest>/Contacts/Blah Test)))(|((EmailAddresses Equal SMTP:blah@<remote forest>)))))", scope "SubTree" under the root "$null".
VERBOSE: New-MailContact : Processing object "<remote forest OU>/Blah Test".
VERBOSE: Creating Mail Contact "Blah Test" with External E-mail Address "SMTP:blahblah@blah.com", Organizational Unit "<remote forest OU>".
VERBOSE: New-MailContact : The properties changed are: "{ DisplayName='Blah Test', AddressListMembership={ '\All Contacts', '\Default Global Address List' }, Alias='BlahTest', EmailAddresses={ 'SMTP:blah@<remote forest>' }, RawExternalEmailAddress='SMTP:blahblah@blah.com', LegacyExchangeDN='/o=<ORG name>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=BlahTest', PoliciesExcluded={ '{26491cfc-9e50-4857-861b-0cb8df22b5d7}' }, Id='<remote forest>/Contacts/Blah Test', RawName='Blah Test', ObjectCategory='<remote forest>/Configuration/Schema/person' }".
VERBOSE: New-MailContact : Saving object "<remote forest>/Contacts/Blah Test" of type "ADContact" and state "New".
VERBOSE: New-MailContact : Previous operation run on domain controller '<remote forest DC>’.
VERBOSE: New-MailContact : Reading new object "<remote forest>/Contacts/Blah Test" of type "ADContact".
VERBOSE: New-MailContact : Previous operation run on domain controller '<remote forest DC>'.
Name                      Alias                                          RecipientType
----                      -----                                          -------------
Blah Test                 BlahTest                                       MailContact
VERBOSE: New-MailContact : Ending processing.

This time, both Netmon and the verbose output from the cmdlet show that the Configuration partition being referenced to set the objectcategory is for the correct domain/forest, and the add request succeeds.

Exchange 2007 and Export-Mailbox with the –IncludeFolders switch

Ben Winzenz [MSFT] — Mon, 26 Jul 2010 19:01:45 GMT

You may have noticed that when you when you run the Export-Mailbox cmdlet, one of the switches available is –IncludeFolders. With this switch, you can specify the folders to include in the export (duh!). However, you may also notice that when you use the –IncludeFolders switch, it includes that folder and all subfolders. This may not be desirable, and may lead to the export taking a long time to complete, especially if there are a large number of sub-folders.

If you don’t like this behavior, and are looking to export only certain folders (for example, just export the Inbox), I want to suggest a workaround. You see, along with –IncludeFolders, there is another switch-ExcludeFolders. Instead of specifying the list of folders to include, you specify the folders you want excluded. Specifically, we tell the Export-Mailbox cmdlet that if it doesn’t match the “exact” path of the folder we want, it should be excluded. Read on for more details.

First, we define a variable to do our “search”. The reason why we have to do this is that we are first running Get-MailboxFolderStatistics, and the folderpath it outputs to is in the form of “/Folderpath”, but Export-Mailbox expects a folder path of “\FolderPath”, so we have to convert the forward slashes to backslashes.

$r = [regex]'/';

Next, we define another variable. This is used to store our “list” of folders to exclude. We use the Get-MailboxFolderStatistics to get a list of all folders that we want to “exclude”. For example, where the folder path is not like the “Inbox”, and not like the “Top of Information Store”. We have to include “Top of Information Store” here because the Inbox is a folder underneath the Top of Information Store, and if it isn’t included, the Inbox won’t be exported either.

From that output, we select only the FolderPath object (because that is all we need), we convert it to a String value (because right now, it is an Object), then change the “/” character to “\” and we store that as a variable.

This can be modified to include other folders as well. Just keep adding things to the where statement, for example $_.folderpath –ne “/Sent Items”.

$exclude = Get-Mailbox "Mailbox Name" | Get-MailboxFolderStatistics | where {$_.folderpath -ne "/" -and $_.FolderPath -ne "/Inbox"} | Select-Object FolderPath | Foreach {$_.folderpath.tostring()} | foreach {$r.replace($_”,”\”,-1)}

The -1 at the end tells it to iterate through all folders in the list.

OK – admittedly, that is a lot of work to get what you need, but it should work. So now, you have a variable that contains an array of all the folders you want to “Exclude”. You are ready to run the Export.

This will perform the export for the 1 user you define. You can also modify the above to run against all users.

Export-Mailbox "Mailbox Name" -FoldersExclude $exclude -TargetMailbox "Mailbox Name" -TargetFolder "Folder Name"

In the below example, it is running against all users except the mailbox you are exporting to, and getting a list of all folders except the Inbox, Top of Information Store, and Deleted Items. Since the –ExcludeFolders doesn’t care if a folder doesn’t exist in a mailbox, we’ll keep the size of the list to a manageable level by only including Unique folder names.

$exclude = Get-Mailbox | where {$_.name –ne “Mailbox Exporting To”} | Get-MailboxFolderStatistics | where {$_.folderpath -ne "/" -and $_.FolderPath -ne "/Inbox" –and $_.FolderPath –ne “/Deleted Items”} | Select-Object FolderPath | Foreach {$_.folderpath.tostring()} | foreach {$r.replace($_”,”\”,-1)} | Sort -Unique

Now we are going to get the list of mailboxes to export.

Get-Mailbox | where {$_.name –ne “Mailbox Exporting to”} | Export-Mailbox –ExcludeFolders $exclude –TargetMailbox “Mailbox Exporting To” –TargetFolder “Folder name”

Now since I don’t have a large lab with lots of mailboxes that have lots of data (and folders) in them, I haven’t verified how much time this method will save, but I believe the time savings here will be substantial. If you try this method out, please let me know if it saves you time.

Exchange 2010 DAG and MaxQuorumLogSize cluster setting

Ben Winzenz [MSFT] — Tue, 15 Jun 2010 17:38:03 GMT

I wanted to get this information out here, as we’ve had a few customers run into this. The issue does not appear to affect core cluster functionality, but does affect the appearance of the cluster.

First, one of my colleagues, Tim McMichael, has a blog that details the different ExBPA rules that can be ignored for Windows 2008 clusters (both Exchange 2007 and Exchange 2010). That blog is located here:

http://blogs.technet.com/b/timmcmic/archive/2009/05/19/exbpa-incorrectly-flags-windows-2003-cluster-rules-on-windows-2008.aspx

I’m not sure if the rules ever got updated for Exchange 2007, but they definitely were not updated for Exchange 2010 RTM (Oops!). These rules will be fixed with Exchange 2010 SP1.

Now, on to the issue.

If you run ExBPA on Exchange 2010 RTM, one of the issues detected (under All Issues) is that the Quorum Log size is too small (see below screenshot from my lab)

You’ll note that the recommendation is to change the current setting from 1024 to 4096.

http://technet.microsoft.com/en-us/library/aa995830(EXCHG.80).aspx details the recommended change and where to modify this setting. If you are astute, you’ll note that the text only discusses Windows 2000 and Windows 2003. That’s because this setting no longer applies to Windows 2008. Unfortunately, you won’t find anything currently documented about this (I’ve asked our friends over in Windows Clustering to please get something documented).

You’ll also see the same recommendation if you run Test-SystemHealth (the Shell version of ExBPA)

So, let’s say you are running Exchange 2010 in a Database Availability Group (DAG), and you decide to make the change. Remember that for a DAG, you have to specify a Witness server during creation. This results in the Quorum model being set to Node and File Share Majority, which will show as follows:

As soon as you modify the MaxQuorumLogSize registry value to anything but the default of 1024, and refresh the Failover Cluster Management interface, you will notice that the Quorum model changes to Other.

As stated previously, this doesn’t affect the actual functionality of the cluster, but if I was a customer, and encountered this situation, I sure wouldn’t be happy, especially seeing that a Quorum model of “Other” isn’t documented anywhere, and isn’t even shown as a valid Quorum model.

The resolution to this is easy. Change the MaxQuorumLogSize back to 1024. No restarts required – just refresh the Failover Cluster Management interface. The Quorum model should change back to “Node and File Share Majority (\\UNC of FSW)” as expected.

Delegates not receiving meeting requests on Exchange 2007

Ben Winzenz [MSFT] — Tue, 28 Jul 2009 20:13:25 GMT

I’ve run into this a few times now, and wanted to share more details on this issue. The scenario in which this occurs is perhaps not quite so common, but then again, depending on how you have folks with Delegates set up, it could have more of an impact on your organization.

In a scenario where there are multiple Exchange organizations (or multiple connected organizations, such as in a Notes –> Exchange co-existance scenario), and the delegate of one person sends a meeting request to someone in the other organization who also happens to have a delegate, and the delegate is configured to receive the meeting requests, the meeting request may not be delivered to the delegate.

Let me see if I can simplify this with a diagram.

This problem is seen because when a Delegate sends the meeting request, the Sent-By field is populated, and this field is what is used for the Sender address. Unfortunately, this field gets populated as “SMTP:mailto:user@organizationA.com.”. This is a problem because anything after the SMTP: is interpreted as the address, and when the mailto: is present, that is picked up as part of the address. Colons are invalid characters in an smtp address, however, so when the message is processed, an invalid sender exception is thrown, and the message does not get delivered to the Delegate.

Another side effect of this issue was that the “Messages queued for submission” performance counter would be incremented on the destination mailbox server, and if you have a monitoring solution in place (such as Microsoft Operations Manager, or System Center Operations Manager), alerts may be generated. More information about this can be found in KB article 953094

The good news is that this was fixed in Rollup 7 for Exchange 2007 SP1 (and would thus be included in both Rollup 8 and 9 and beyond since Rollups are cumulative), so unless you are behind on your rollups, hopefully you won’t encounter this situation. It’s also worth noting that the fix (which works by simply stripping out the mailto: portion) needs to go on Hub Transport servers. So make sure that your Hub Transport servers are running Rollup 7 or higher!

Exchange 2007 Sp1 Cluster Install/Recovery Issues

Ben Winzenz [MSFT] — Fri, 20 Feb 2009 02:25:19 GMT

One of the problems that I’ve seen customers encounter several times now when creating a new Clustered Mailbox Server (CMS), or attempting to recover an existing CMS is a failure during setup when the Network name resource is brought online. The specific error that is seen is as follows:

The computer account '<Exchange Virtual Server Name>' was created on the domain controller \\<pdc emulator name>, but has not replicated to the desired domain controller (<local DC name>) after waiting approximately 60 seconds. Please wait for the account to replicate and re-run setup /newcms.

Most (if not all) of you probably already know, but the Cluster portion of setup is completely separate from installing the Mailbox role. The Mailbox Role can be installed as part of the same instance of setup, but it will complete prior to the Clustered Mailbox Server portion of setup. The issue encountered above appears to be isolated to Exchange 2007 clusters that are running on Windows 2003 only.

The issue stems from how the Windows 2003 Cluster service works. When Exchange setup runs, it makes a call into the Cluster API to create the computer account for the Exchange CMS. It is important to note here that Exchange is not what is creating the computer account, rather the Cluster service is. At this point, what happens is that the Cluster service attempts to contact the PDC Emulator for the domain, and creates the computer account on that Domain Controller. If the PDC Emulator FSMO role happens to be in a different Active Directory Site than the Active Directory Site where you are installing the Exchange cluster, then there may be a delay in getting that computer account replicated to a local Domain Controller. This issue is also observed because Exchange setup will now use a Domain Controller in the local AD site rather than also automatically going to the PDC Emulator. This change was first made in Sp1 for Exchange 2007. So given the above, let’s consider the following chain of events.

1. Exchange setup calls in to Cluster API to create the computer account for the CMS.
2. Cluster API contacts the DC holding the PDC Emulator role, and creates the computer account.
3. Exchange setup contacts a DC in the local AD site and checks for the existence of the CMS computer account.

At this point, if either the computer account doesn’t exist, or if the computer account exists but is disabled on the local DC, then setup will fail with the above error. Re-enabling the computer account on the local DC will not fix this issue, as the computer account was created or reset on the PDC Emulator, and the account on the local DC no longer matches what is on the PDC Emulator.

Further complicating the issue is that when you re-run setup /newcms, the entire procedure appears to be repeated. If you watch in Cluster Administrator, you will see that the group that was created for the CMS, along with all resources inside the group, is deleted. Now at this point, the only resources that exist are the IP Address resource, and the Network Name resource. The CMS group will then be re-created, and the IP address resource, and Network Name resource will also be re-created. Re-creating the Network Name resource causes the computer account to be reset on the PDC Emulator, and causes it to be disabled on any other DC’s (that is my understanding here at least). So you’re right back to square one.

How do we get around this? Pre-staging the computer account on the PDC Emulator, and allowing that to replicate to the local DC does not work, because the pre-staged account will be deleted and re-created by the Cluster service during setup. I have thus found the following 2 workarounds that should allow setup to continue past this section.

1. Move the PDC Emulator role to a Domain Controller in the local AD Site.

Pros: Relatively easy to do, should not cause any additional issues with Active Directory.
Cons: Requires a functional design change to Active Directory Infrastructure. May require approval of multiple teams.

2. Block the Cluster service from communicating with the PDC Emulator.

Pros: Works except in rare situations where the PDC Emulator is in a different AD site, but the same IP subnet. Fairly easy to implement.
Cons: not “officially” supported/tested by the Exchange Product Group.

Let’s talk a little more about workaround 2. What does this involve? Actually, just a few minor changes. You need to modify the local Hosts file on the Exchange Server (located in C:\Windows\System32\Drivers\Etc – look for the file Hosts with no extension), and add the following entries to the bottom of the file.

127.0.0.1 PDCEmulator.FQDN.com
127.0.0.1 PDCEmulatorNetBIOS

Save the Hosts file, the run ipconfig /flushdns, and nbtstat –R

Run setup again, and the operation should be successful. What’s the difference you ask? Well, if you prevent the Cluster service from communicating with the PDC Emulator, then it will fall back to using a local DC. When it creates the computer account on a local DC, intra-site replication is almost instantaneous, so Exchange is able to find the correct computer account on the DC that setup chooses, and is able to go on past this portion of setup.

As mentioned above, this issue can be encountered when setting up a new cluster (setup /newcms), or if you are recovering an existing cluster (setup /recoverCMS). The second scenario would be especially common if you are testing your DR procedures, and performing a failover/activation to an SCR Target.

This issue should not be present in Windows 2008, as the cluster service is smarter, and when the PDC Emulator is detected as being in a different site, the cluster service should automatically use a local DC for operations such as this.

Disabling LDAP Encryption and Signing for Netmon on an Exchange server

Ben Winzenz [MSFT] — Mon, 15 Dec 2008 19:45:59 GMT

It’s been a while since my last post, but I’ve been super busy. I wanted to post something that I often have to do with customers.

There may be times when in order to further troubleshoot a problem, you need to capture a Network Monitor trace. Netmon is very helpful in finding delays, and LDAP errors. However, there is one major hurdle. Virtually all LDAP traffic is signed and sealed, and encrypted. This unfortunately makes viewing the queries and responses impossible by default. You would see something similar to the following.

Protocol Name	Description
LDAP	LDAP: GSS-API Encrypted Payload

And that is all you will see. Of course, this makes troubleshooting much harder, because you can’t see what queries are being issued, or what the Domain Controller is responding with. Fortunately, there are ways to turn off LDAP encryption. I have gathered together the following list of things that need to be done in order to ensure that all forms of LDAP encryption are disabled. Some steps are only for Exchange 2003, and others are only for Exchange 2007. Where specific to a version, I have included which version it applies to.

Here are the steps to turn off LDAP encryption. There are a few different places we have to do this in order to catch everything.

These steps apply to both Exchange 2003 and Exchange 2007

1. Modify the Local Security Policy.

Under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. Find the policy setting “Network Security: LDAP client signing requirements”. Note that the default is set to “Negotiate signing”. On the Domain Controller side, it is actually set to None by default, but since the client requests to negotiate, it will always be signed if supported. Set this to None on the “client” (the Exchange server is the client in this case). You should also check the Default Domain Controller group policy, as if the LDAP signing policy is set to Negotiate, or Require, you will need to modify the Domain Controller policy as well.

2. Set the following registry key and value on the Exchange server. If the AdminDebug key is not present, add it. This registry value disables Encrypted LDAP Bind’s. Normally, once a Bind request is issued, all LDAP traffic sent after that will be encrypted.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\AdminDebug

New DWORD value: ADsOpenObjectFlags

Data Value: 0x3

Per KB 325465, the following values correspond with the following actions. As you can see, by setting the value to 0x3, we disable both Signing and Encryption.

Value Data (Hexadecimal) Disables
1 Signing
2 Encryption
3 Encryption and Signing

This step is for Exchange 2007 only

3. Add the following registry key to disable LDAP encryption for the Exchange 2007 DSAccess process

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess

New DWORD value: Disable LDAP Encryption

Data Value: 0x1

This step is for Exchange 2003 only

4. Per KB818479, to disable signing and encryption for traffic created by Exchange 2003 Admin tools, add the following value

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange

New DWORD value: DebugLDAP

Data Value: 0x1

Once you have set all of these options, you should be good to go. Get another Netmon trace, and you should now be able to view the contents of every LDAP frame. On rare occasions, you may need to reboot to get all of these settings to be correctly read. Also, don’t forget to undo any changes that are made once you are done. Signing and Encryption of LDAP traffic is a good thing to have in place for security reasons, so only leave this disabled as long as you need to.

Move Mailbox from a CSV Import file

Ben Winzenz [MSFT] — Mon, 02 Jun 2008 16:53:00 GMT

A while back, I had promised to write another post detailing how to use Import-CSV and then run Move-Mailbox against the users in that CSV file. Well, quite a bit of time has passed since then, and getting this figured out proved a little more difficult than I thought it would be. I finally got it worked out, though.

Here are the details of the setup. You have users that you want to split up between several target databases. In my CSV file, I have 3 columns, as outlined below (sample file)

Name, Username, TargetDB

A user, auser, "Server\Storage Group\Mailbox Database"
B user, buser, "Server\Storage Group\Second Database"
C user, cuser, "Server\Storage Group\Third Database"

The TargetDB column means that you will have to do a little bit of legwork in determining where you want to put the users, and populate that column, but it shouldn't take too much effort.

Next, we'll start writing the script itself.

##################################################################
#                                                                                                                                                                #
#                                   Script to move mailboxes multithreaded from CSV import                                    #
#                                                                                                                                                                #
##################################################################

write-output "Moving mailboxes from CSV import"

#First we are going to import from your csv file
#where the CSV file contains 3 columns. Name, Username and TargetDB

$users = import-csv c:\userimport.csv

#Now we are going to filter the list down and get a
#list of just the users on the first database

$db1 = $users| where {$_.targetdb -like "*mailbox database"} |
foreach { $_.name } | get-mailbox

#getting a list of the users on the second target database

$db2 = $users | where {$_.targetdb -like "*Second Database"} |
foreach { $_.name } | get-mailbox

#Repeat the above line for each additional database that you have.

#Now we move each group of users to their respective databases

$db1 | move-mailbox -targetdatabase "E2K7-2\First Storage Group\Mailbox Database" -confirm:$false -maxthreads:10

$db2 | move-mailbox -targetdatabase "E2K7-2\Second Storage Group\Second Database" -confirm:$false -maxthreads:10

#Repeat the above line for each additional mailbox database that you have

write-output "Completed Mailbox moves from CSV file"

I first tried to get this working with just one command, but kept failing on the target database portion. When I was creating my arrays, I had a separate array for the target database, but the problem I kept running into was that the value for the array was only being recognized as the last value in the CSV file. So if Third Database was the last value for TargetDB, that was where all users ended up being moved. After multiple failed attempts to correct that, I decided that the best way to approach this would be to filter the CSV and move all users with a common target database, then move on to the next group. It still achieves the desired result of being able to take advantage of multi-threading, and it also does everything in one shot.

If you have any suggestions for improvement, please feel free to pass on your suggestions.

MOM Exchange Management Pack alerts

Ben Winzenz [MSFT] — Mon, 31 Mar 2008 17:12:40 GMT

Part of my job involves supporting the Exchange Management Pack for Microsoft Operations Manager (MOM). In doing so, we sometimes come across things that don't really make a lot of sense (or at least they don't to me). Take the following scenario.

With MOM, you can create Mailboxes that MOM then uses to make sure it can log on to at specified intervals. This is performed via a simple MAPI logon. The Exchange Management Pack has a script that performs this action, and it triggers by default every 15 minutes. When you deploy and configure the Exchange Management Pack, you can choose to create a mailbox for the entire server (per-server monitoring), or you can create a separate mailbox for every single mailbox store.

When the MAPI logon script runs, it logs an event based on the result. The expected result is obviously a Success, but if it fails, there are several different reasons this could be occurring. Many of these errors are easy to interpret, and have prescribed actions that can be done to troubleshoot/fix the issue.

One event that may get logged is a MAPI logon failure because the logon timed out. At first glance, that may not really make sense - if a logon is going to work, it is going to work. Keep in mind, however, that MOM uses scripts to perform the tests, and we could simply be dealing with the script taking a long time to run. This results in a sort of false-positive. The MAPI logon doesn't actually fail, and no clients are reporting issues, yet you have this glaring error in your MOM console.

The default timeout for the script itself is 30 seconds. While this is sufficient in most cases, there may be circumstances where 30 seconds is insufficient, and is resulting in the script timing out (even if it is almost done...), which then results in the error being logged to MOM. The solution is to modify the MAPI logon script itself and increase the timeout value. In the script, you will find a line

var TIME_OUT_THRESHOLD = 30000

If you change the threshold to a higher value - 90000, the errors will go away because you are giving the script more time to run.

Exchange 2007 Single Copy Cluster Changes

Ben Winzenz [MSFT] — Fri, 28 Mar 2008 16:51:49 GMT

Single Copy Clusters are the continuation of how clustering was implemented with previous versions of Exchange. It is a standard cluster implementation which utilizes Shared Storage (i.e. SAN) and allows all nodes of the cluster access to the shared storage. One node of the cluster will "own" the resources for that cluster group, and all nodes of the cluster maintain communication to ensure that the resources don't get mistakenly taken over by another node. A quorum is used to maintain ownership information.

That being said, Exchange 2007 does make some slight changes to how you must implement the cluster. I do want to note that setting up a cluster in Exchange 2007 is MUCH MUCH easier, but there are a few *gotchas*. First, if you are familiar to clustering with Exchange 2003, you may be inclined to pre-create the Cluster Group for the Exchange Virtual Server, and pre-populate it with the Physical Disks you will be using. Don't. Instead, all you need to do is create your Physical Disk resources in the default Cluster Group.

An overview of how to install Exchange 2007 Single Copy Cluster on Windows 2003 can be found here.

http://technet.microsoft.com/en-us/library/bb124899.aspx

and for instructions on how to install the Active Clustered Mailbox Role in a Single Copy Cluster, refer to

http://technet.microsoft.com/en-us/library/bb123969.aspx

Once you have finished the Active Mailbox role, you will find that Exchange 2007 setup will create the new Exchange CMS group for you. The only step that remains is that you need to finalize configuration of the cluster by moving the physical disk resources from the default Cluster Group into the new Exchange CMS cluster group, and then configuring the dependencies as appropriate. In Exchange 2007, you will have a separate resource for each Storage Group/Mailbox Store, so it is important to make sure that you get the dependencies correct.

Exchange 2007 SP1 Setup Domain Controller Requirements

Ben Winzenz [MSFT] — Mon, 03 Dec 2007 19:30:20 GMT

OK. I've heard lots of complaints about Exchange 2007 and the fact that when you run setup, the pre-requisite checks will fail if you have multiple domains in your forest, and one of those domains doesn't have a Windows 2003 SP1+ domain controller. That's fair enough. Some of those child domains may not have an existing Exchange server, or may not even host exchange-enabled objects.

As many of you know, we changed the behavior of setup for Sp1, however the documentation still is being misinterpreted. The new pre-requisite check will now check child domains during the /preparelegacyexchangepermissions portion of setup, and will look for the "Exchange Domain Servers" group. If it finds that group present, then that domain must contain a Windows 2003 Sp1+ DC. If you are in this situation, you have 2 options. If you don't have any Exchange objects in that child domain, AND YOU ARE SURE OF THIS, then you can remove the Exchange Domain Servers group from that domain. When you then run setup again, that domain will be skipped from the pre-requisite check.

See http://msexchangeteam.com/archive/2007/11/01/447411.aspx for more details around this.

Alright, so now you know about the SP1 install requirements, and when a Windows 2003 Sp1+ DC is required. The next question is, can I temporarily install a Windows 2003 SP1+ DC in a child domain that I am not ready to upgrade to Windows 2003 yet? The answer is that this is not a good idea. In fact, I'd go one step further and say that this will create huge problems. Let's talk about why.

Exchange 2000/2003 stores exchange-related information in the Personal and Public property sets. These property sets contain both Active Directory information (such as Street Address, phone number) AND Exchange information (msExchHomeServerName, proxyaddresses). It was decided that it would be a good thing to have Exchange store it's attributes in a separate Exchange-specific property set, so Exchange 2007 creates two new property sets, Exchange Information and Exchange Personal Information. When /preparelegacyexchangepermissions is run, part of it's operation is to move the existing Exchange attributes into the new Exchange property sets.

See http://technet.microsoft.com/en-us/library/bb310768.aspx for more information about these property sets.

So what's the problem? The problem is that these new Exchange property sets can only get replicated between Windows 2003 Sp1+ Domain Controllers. If you introduce a temporary Windows 2003 Sp1 Domain Controller in a child domain just so you can run setup to install the first Exchange 2007 server, then you later remove it, the other Windows 2000 Domain Controllers in that domain do not know about the new Exchange property sets. Since the Exchange attributes have already been moved to the new property sets, you can see how this could be disastrous for your company. Imagine having mailboxes in a child domain and the domain controllers in that domain no longer have any knowledge of any Exchange attributes. Not Good.

The moral of the story here is to make sure that you understand the pre-requisites and don't shoot yourself in the foot by trying to work around the setup requirements.