Tex-MX

How to move a folder using MFCMAPI

Had a user today complain that their "Junk Mail" folder got moved to a subfolder of "Notes".  Couldn't move it back via Oulook.  Found this handy website to help:

http://www.hedonists.ca/2010/03/09/how-to-move-a-folder-in-mfcmapi

Convert a mail-enabled public folder to a shared mailbox in Exchange 2007

 

1. Create the new Shared mailbox per the instructions here.
1. Give it the same name as the public folder being converted.
2. Make sure the users who have access to the public folder are added to the MBX_xxxxxx security group so they have Full Access and Send-As rights to the new mailbox.

2. Using PowerShell , note the LegacyExchangeDN of the mail-enabled public folder:
1. Get-MailPublicFolder <pf-smtpaddress> | Select LegacyExchangeDN
2. (i.e. /O=ORG/OU=ADMIN GROUP/CN=RECIPIENTS/CN=Folder-Name887CE6C3409E34A2848C4BB5E42229C7547F86)

3. Using PowerShell, note the SMTP addresses assigned to the public folder
1. (Get-MailPublicFolder <pf-smtpaddress>| Select emailaddresses).emailaddresses | where {$_.prefixstring -eq 'smtp'}
2. (SmtpAddress     : Folder-Name@contoso.com

AddressString   : Folder-Name@contoso.com

ProxyAddressString : smtp:Folder-Name@contoso.com

Prefix : SMTP

IsPrimaryAddress   : False

PrefixString    : smtp}

4. Mail-disable the public folder and allow a few minutes for AD to replicate this change.  Mail destined to the original public folder may bounce during this time frame.
5. Add the LegacyExchangeDN value to the new shared mailbox as an X.500 email address.  This will allow mail originally destined for the public folder to be delivered to the new shared mailbox instead.  This is to support replies to older messages and new messages sent using the Outlook Name cache.

6. Add the SMTP addresses to the new shared mailbox if they are not already auto-assigned by the email address policy.

Script to add Public Folder replicas all the way down a subtree

So I'm in the process of trying to migrate my public folders from Exchange 2003 to Exchange 2007.  As part of the process (since my public folder database is SO HUGE!) I'm moving small subsets of folders at a time instead of performing a "Move All Replicas" task.

To facilitate this I'm adding the new 2007 pub databases to the replica list of a sub-folder first, allowing replication to happen and then removing the 2003 pub databases from the replica list.

The trick is getting the 2 new 2007 pub databases added to the list without necessarily knowing what's already in the replica list and doing all of this in a script, not a GUI.

Below is the script I wrote to do this.  I simply type the script name at the PowerShell command line and then pass the path of the root folder I want to start with on the command line.  The script starts from that root folder and adds my 2 new 2007 servers to the list all the way down the tree.

[string]$path = $args[0]
Write-Host $path
$server1 = Get-PublicFolderDatabase -Server servername1
$server2 = Get-PublicFolderDatabase -Server servername2

$folders = Get-PublicFolder $path -Recurse
foreach ($rootfolder in $folders) {
 $rootfolder.Replicas +=$server1.Identity
 $rootfolder.Replicas +=$server2.Identity
 $rootfolder | Set-PublicFolder}

Script to create Shared Mailboxes consistently

If you’ve followed the instructions for creating shared mailboxes using PowerShell you know its a little clugey.   However, since the parameters for setting one up is fairly consistent except for the name and who has access to it, I’ve created the following script that can be used to create them.

 

 

You must have the following components installed in order to run it.

· PowerShell

· Exchange 2007 Management Console and Shell

· Quest ActiveRoles snap-in for Powershell (free download here)

· PowerShell must be run in the context of a user account that has rights to create new objects in AD

· You must set your PowerShell execution policy to Unrestricted (open PowerShell, type Set-ExecutionPolicy Unrestricted)

 

When you run the script from within PowerShell, it will perform the following:

 

1.    Check to make sure the Exchange & Quest Snap-ins are present and if not, add them

2.    Query the user for information about the new shared mailbox (name of the mailbox, etc).

3.    Based on the information provided, it will create the new mailbox in one of two OUs (Site1 or Site2)

4.    It will then create a new security group in AD with a MBX_ prefix and grant members of this group Full Access and Send-As rights to the new mailbox

5.    Log all of this in a log file found in the same folder as the script for troubleshooting purposes.

 

Once the script completes and creates the mailbox and security group, all you have to do to complete the process is use AD Users & Computers to add user accounts to the new security group to grant them access.

 

You'll need to edit the script to fit your environment (OU paths and Exchange server names, etc)

 

The script is after the jump...

Populate the "folder path" field for mail-enabled public folders in the address book

If you're like me you hate when you get a request from a user to modify something with a mail-enabled public folder because users NEVER tell you the path to that folder in the folder hierarchy.  You can find it via powershell if you want:

Get-MailPublicFolder "smtp@address" | Get-PublicFolder | fl Name, ParentPath

Name    : Folder Name
ParentPath : \Parent Folder Name\Sub folder name\

If you look in the address book, each mail-enabled public folder in the list has a "folder path" property that never gets populated.  I wish I knew why Microsoft made this information available but didn't make it easy to populate the values - you'd think it would just automatically be able to look that information up when it generates the address list - but sadly, NO!

Or you could run a powershell script to set each one of them automatically.  You'll have to schedule the script to run regularly to make sure the values are up to date though.  You'll also need the Quest ActiveRoles snapin for powershell. 

Here's the script I wrote to accomplish this:

$mailpub = Get-MailPublicFolder -ResultSize unlimited
foreach ($folder in $mailpub) {
 $pubfolder = Get-PublicFolder -Identity $folder
 $folderpath = $pubfolder.parentpath + "\" + $pubfolder.name
 $qadpub = Get-QADObject -IncludeAllProperties -Type publicfolder -Identity $folder
 Set-QADObject -Identity $qadpub -ObjectAttributes @{folderPathname=$folderpath}}

Have fun!

Exchange 2007 and Spaces in the Alias field

I've not been able to find much documentation about this online yet, but I discovered this issue in my Exchange 2007 Migration Lab: Exchange 2007 doesn't like spaces in the alias field of mail-enabled objects.

These spaces will cause any migration of the object into the Exchange 2007 system to fail with the following error:

WARNING: Object contoso.com/Microsoft Exchange System Objects/Consumer

Support has been corrupted and it is in an inconsistent state. The following

validation errors have occurred:

WARNING: "Consumer Support" is not valid for Alias. Valid values are: Strings

formed with characters from a to z (uppercase or lowercase), digits from 0 to

9, !, #, $, %, &, ', *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more

periods may be embedded in an alias, but each one of them should be preceded

and followed by at least one of the other characters. Unicode characters from

U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a

best-fit US-ASCII string in the email address which is generated from such an

alias.

Before you can begin the migration of your AD objects to Exchange 2007, you must update all objects in AD to remove the space.  In my case, I opted for replacing the space with an underscore (i.e. in the above example, “Consumer Support” will become “Consumer_Support”).  This change should only affect the alias property in AD and not the display name.

I wrote the following procedure involving AD Users & Computers and Powershell to correct the issue in my environment prior to installing the Exchange 2007 Schema updates:

• Create an AD Users & Computers search query to search all exchange-enabled objects.  Include the "Exchange Alias" filed in the column headers

• Export this list to a tab-delimited file.

• Open this file in Excel, change the "Exchange Alias" column header to just "Alias", and re-save as a CSV file

• Open Powershell

• $mailobjects = import-csv exportedfile.csv

• $mailboxes | Where-Object {$_.alias -match " "} | Export-CSV bad_exchaliases.csv

• Open in Excel, remove all columns but "Alias"

• Duplicate the "Alias" column, name it New_Alias

• In the duplicated column, find/replace all " " with "_"

• Save CSV file

• $badaliases = import-csv bad_exchaliases.csv

• $cred = Get-Credential (input credentials with rights to modify all objects)

• foreach ($object in $badaliases) {Set-QADObject -Identity $object.Alias -ObjectAttributes @{mailnickname=$object.New_Alias} -Credential $cred

Update: Found this page on TechNet:

Tracking transaction log generation per hour

I've been working on the Exchange 2007 Mailbox Storage Calculator for my Exchange 2007 migration project.  The spreadsheet asks for the number of logs generated per hour so it can appropriately calculate the bandwidth needed for CCR and SCR log shipping.

Below is the script I wrote to do this for me.  Simply edit it to fit your Exchange server.  Since I have mulitple servers, I wrote one for each server, editing the name of the log file to match.  Then i created a batch file that runs each script for each Exchange server and created a scheduled task to re-run once per hour every hour.

FIlename: Count-Logs-EXCHSRVRNAME.ps1

function writetolog([string]$stringtowrite="*")
 {
     $datetime = (Get-Date).datetime
     Add-Content $logfile "$datetime : $stringtowrite"
 }

#the path to the log file you want to generate containing the count of
#transaction logs
$logfilename = "C:\exchserver1-logcount.log"

#Make sure the count log file exists before attempting to write to it
if (Test-Path $logfilename) {Write-Host "Log file exists.";$logfile = $logfilename} Else {Write-Host "Creating log file $logfilename";$logfile = New-Item $logfilename -Type file}

#Path to the transaction logs for each storage group
$sg0path = "path to logs for SG0"
$sg1path = "path to logs for SG1"
$sg2path = "path to logs for SG2"
$sg3path = "path to logs for SG3"
$sg4path = "path to logs for SG4"

#Count the log files in each path, add them together and write that to the
#count log.
$sg0count = (get-childitem $sg0path).count
$sg1count = (get-childitem $sg1path).count
$sg2count = (get-childitem $sg2path).count
$sg3count = (get-childitem $sg3path).count
$sg4count = (get-childitem $sg4path).count
$date = get-date
writetolog ($sg0count + $sg1count + $sg2count + $sg3count + sg4count)

The count log file will contain data for each hour in the following format:

Tuesday, August 11, 2009 10:00:15 AM : 121
Tuesday, August 11, 2009 11:00:17 AM : 137

Simply import these logs into Excel, massage the data as needed to get an accurate count of how many log files are generated each day.  You'll need to calculate the difference between each line of data to know how many logs were generated since the last count was taken since the script just counts the total number of logs in the directory.  You may need to add up the number for all the log files you generate if you're generating one for each server you have.

Don't forget to multiply by 5 before inputing the number into the Storage Calculator spreadsheet, though!  Exchange 2007 logs are 1MB in size while Exchange 2003 logs were 5MB in size!

Get the top 10 mailboxes across all your Exchange 2003 servers

$servers = 'server1','server2',etc, etc,etc
Get-Wmiobject -namespace root\MicrosoftExchangeV2 -class Exchange_Mailbox -computer $servers | sort-object Size -Descending | select-object -First 10 MailboxDisplayName,Servername,StorageGroupName,StoreName,Size | Export-Csv Top10Mailboxes.csv

Powershell: Which accounts were created in the last X days?

get-qaduser -SizeLimit 0 | Where-Object {$_.creationdate -gt [DateTime]::Now.AddDays(-7)} | Select-Object Type, displayName, Email

Sent with Microsoft Exchange Server 2007 SP1

Public Folder Mailflow

Last week I installed a new exchange server into the Dallas Administrative Group and the Dallas Routing Group.  Default installs of exchange include a mailbox database and a public folder database.  I wasn’t really concerned with the public folder database (not intending to keep it) so I just left it there for now (planning to delete it at a later date) and proceeded to create a journaling mailbox on the mailbox database.  (This journal mailbox isn’t pertinent to this post other than it only RECEIVED mail and didn’t DELVIER any of it).

 

Today I noticed that there were a LOT of messages backed up in the various queues on the new server (Ex3) – including over 2900 messages in the Local Delivery Queue destined for public folders on OTHER servers!  This, I thought was quite strange.  Why would those messages be delivered to Ex3 if it doesn’t host any of the public folder replicas???

 

However, what I didn’t notice at first were ACLs on the “Connection” & “Relay” access on the SMTP virtual servers on every other Exchange server in the Org.  So the new server (Ex3) couldn’t telnet to any other exchange server to deliver messages.  The Journal mailbox was receiving messages just fine because the default configuration on SMTP virtual servers when you install Exchange is to accept all authenticated connections – which would include other Exchange servers.

 

So I did a little research.  Public folder routing happens like the following:

 

1.       Message comes in from the internet.

2.       Categorizer looks up homeMDB for the recipient where it finds the DN of the top-level public folder hierarchy.

3.       Next, the categorizer looks up the top-level hierarchy object that is retrieved from the folder's homeMDB attribute to obtain a list of all the servers in that hierarchy from the msExchOwningPFTreeBL value.

4.       To determine which public folder store or server to deliver to, the categorizer uses the following criteria: 

·              Does one of the public folder stores exist on the local server? If so, Exchange uses that store.

·              Does one of the public folder stores exist on an Exchange server in the local routing group? If so, Exchange uses that store.

·              Does one of the public folder stores exist on any Exchange server? If so, Exchange uses that store. Otherwise, Exchange uses the first store in the list.

 

In my case, there are 3 servers in the Dallas routing group: Ex1, Ex2, and (new) Ex3.  Ex1 and Ex2 both receive messages from the internet edge servers directly.  Ex1 has a public folder database but Ex2 does not since it’s just basically a Front-End server that’s also used for message routing.  The folder hierarchy is homed on Ex1.

 

So – Ex2 was receiving messages from the internet destined for public folders.  Based on the 2^nd bullet point in #4 above, it would deliver messages to the public folder store on either Ex1 or Ex3 since they were both in the local routing group and had a public folder store in the hierarchy.  BUT since Ex3 couldn’t telnet TO any other server and could only RECEIVE, messages backed up in the local delivery queue.  That’s when I added the IP address for Ex3 to the SMTP virtual servers on all the other Exchange servers in the Org.

 

The queues on Ex3 to the other routing groups emptied quite quickly once telnet was working – but what they were delivering was hierarchy messages from Ex3 to the other public folder stores (to announce there’s a new public folder store on Ex3 and request a hierarchy replication back to Ex3 so it knows what folder is located where, etc).  However, the Local Delivery Queue on Ex3 wasn’t moving at all and this made me a little concerned.

 

What I didn’t realize at first was that the PF store on EX3 had to wait for ALL public folder hierarchy replication to complete and come back to EX3 with the full hierarchy before EX3 knew where to deliver those messages stuck in the queue – which explains why the local delivery queue took so long to empty.

 

After all the messages got delivered successfully, I verified that there were NO replicas in the public folder store on EX3 and promptly deleted it so that it wouldn’t be included in public folder mail delivery again.  Whew!