Configuring Virtual Organizations and Address List Segregation in Exchange 2007

dyoung, this is by default. When you are a seperating your address lists your outlook client should *not* be able to see everybodies elses address list.

Hi there,

I have read the articles on creating a hosting env. with Exchange 2007. One issue that has nowhere been addressed is the use of the postmaster account for sending out NDR's. Essentially you want to have a different postmaster account per virtual company, so NDRs seem to be originating from postmaster@virtualcompany01.com. With the default installation the account is postmaster@hostingorg.local (or something alike). In Exchange 2003 you could fix this with editing the IIS meta database with MetaEdit2.

How must this be accomplished with Exchange 2007 ? Postmaster accounts are now set per transport server, where in my opninion this should be per recieve connector.

Can you please tell me how to deal with this in E2k7 ? Do you need a complete transport server per virtual company ?

Thanks in advance.

Best regards,

Ronald Top

After following this article I have found that each company user can no longer see any of the address lists whilst in Outlook. The following command found in the "Create a Security Group for all Hosted Groups" section seems to hide these:

Add-ADPermission –Identity “CN=Address Lists Container,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com” –User “All Hosted Groups SG” –AccessRights ReadProperty -Properties "Open Address List" –Deny

I have double checked all the commands entered with no luck. One thing I have noticed in the article section "Modify Permissions on the Address List" the first line reads:

"Use the following procedure to modify the default permissions on the All Address Lists container."

Although there are no commands following this that actually modify the permissions on the "All Address Lists container". Is this just merely a typo or is there a command missing.

If anyone could assist with this, thanks in advance.

Thanks for the great article. One thing I found was the difficulty to update a large number of accounts which were already created with the msExchQueryBaseDN value. I have compiled which I hope will be helpful for others in the smae situation.


$strFilter = "user"

$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = "LDAP://ou=Fabrikam,OU=Companies,DC=contoso,DC=com"
$objSearcher.SearchScope = "Subtree"
$objSearcher.PageSize = 1000

$objSearcher.Filter = "(objectCategory=$strFilter)"
$colResults = $objSearcher.FindAll()

foreach ($i in $colResults)
   {
       $objUser = $i.GetDirectoryEntry()
$UserDN = $objUser.distinguishedName
$UserN = $objUser.Name
Write-Host "Processing User: " $UserN
$user = ([ADSI]"LDAP://DC1:389/$UserDN").psbase
$user.Properties["msExchQueryBaseDN"].Value = "ou=Fabrikam,OU=Companies,DC=contoso,DC=com"
$user.CommitChanges();
Write-Host ""
   }

Thansks for that great article. Is there an other solution for the "unsupported" configration ?. This do describes a "total segregated" configuration without the default GAL. How can i implement, that company1 is using GAL1 and AL1, company2 is using GAL2 and AL2  and the hoster and other services (fax, blackberry etc) can still use a "global GAL".
An other problem is see is the modification at the OU-Level. I understand, that the dsheuristics modification makes sense (similar zu access based enumerations ad file shares). But is it a good idea to remove permissions at OU-Level ("To accomplish this task, you must remove from each organizational unit the permissions assigned to the Authenticated Users group and the Everyone group, if it exists"). How far are be from a "standard" ?.
There should be a solution adding a GAL/AL with a filter and permissions to the GAL/AL without modifying AD-Permissions at OUs.

Are there more details to "Attempting this configuration will cause problems with the check names functionality which will prevent users from creating Outlook profiles" ?.