kj
Fri Mar 28 09:41:32 PDT 2008
"Gregg Hill" <bogus@nowhere.com> wrote in message
news:O0vge%23OkIHA.2276@TK2MSFTNGP05.phx.gbl...
> Ed,
>
> Can you tell me where these attributes are located? ADUC or Exchange
> manager? When I Googled, one of the first hits I got was this thread!
> Dang, I hate it when that happens!
>
> Thank you!
>
> Gregg Hill
Company is an AD object attribute often used for the user. The extended
attributes are old exchange legacy stuff when the two were seperate
directories.
In short, your custom recepient policy can ldap query object attributes to
generate addresses based on those conditions. Ie,
user "companyA", email address = user@companyA.com , user "companyB", email
address =user@companyB.com
Somewhere there's a step by step for creating a custom recepient policy to
configure for multiple comanies within a single exchange organization.
>
>
> "Ed Crowley [MVP]" <curspice@mvpsnospam.org> wrote in message
> news:%2329aerOkIHA.4076@TK2MSFTNGP05.phx.gbl...
>> You're smart enough to know how to Google! You could use just about any
>> other attribute as well, like company.
>> --
>> Ed Crowley
>> MVP - Exchange
>> "Protecting the world from PSTs and brick backups!"
>>
>> "Gregg Hill" <bogus@nowhere.com> wrote in message
>> news:%23B6tpGKkIHA.4480@TK2MSFTNGP03.phx.gbl...
>>> Ed,
>>>
>>> You claimed that "So the approach I suggest should be foolproof." Well,
>>> you didn't take into account that this fool has no idea what you mean by
>>> "extension attribute 10"!
>>>
>>> So, it is off to Google I go to find out what you mean by that.
>>>
>>> Thank you for the additional information to get me going in the right
>>> direction!
>>>
>>> Gregg Hill
>>>
>>>
>>>
>>>
>>> "Ed Crowley [MVP]" <curspice@mvpsnospam.org> wrote in message
>>> news:%23Th%23YMIkIHA.5396@TK2MSFTNGP06.phx.gbl...
>>>> Comments inline.
>>>> --
>>>> Ed Crowley
>>>> MVP - Exchange
>>>> "Protecting the world from PSTs and brick backups!"
>>>>
>>>> "Gregg Hill" <bogus@nowhere.com> wrote in message
>>>> news:e$Mjz$HkIHA.3888@TK2MSFTNGP03.phx.gbl...
>>>>> Hello!
>>>>>
>>>>> Cross-posted to the Exchange group in case gurus there have a good
>>>>> answer.
>>>>>
>>>>> I want to set up an SBS server to receive mail for two domains and to
>>>>> be able to send from those two domains and not just send from the
>>>>> default Exchange account. I have read
>>>>>
http://support.microsoft.com/kb/268838/en-us and it says to have all
>>>>> domains in the default policy. I have read other articles that say to
>>>>> create a new recipient policy for the domain.
>>>>
>>>> They're both right. Best practice is to put all valid domains in the
>>>> default policy and then create other higher-priority policies with
>>>> appropriate filters that apply to recipients. In general, your
>>>> lowest-priority additonal policy would match everyone so it would apply
>>>> to all users that higher-priority filters don't touch, which means the
>>>> default policy never comes into play.
>>>>
>>>>> I had ChooseFrom (with SmartFrom and SmartReply) working with domain
>>>>> aliases, but that died a while back...not sure why...could be related
>>>>> to installing Vamsoft ORF for spam filtering (NDR states: You do not
>>>>> have permission to send to this recipient).
>>>>>
>>>>> I am thinking that ChooseFrom (with SmartFrom and SmartReply) could
>>>>> help meet my goals.
>>>>>
>>>>> My goals are:
>>>>>
>>>>> 1) To have 3 users out of 25 who will have both domainA.com email and
>>>>> domainB.com email, and to be able to send from either one.
>>>>
>>>> You'll need ChooseFrom for the sending part. You could put a "AB" in
>>>> extension attribute 10 and then create a recipient policy with the
>>>> highest priority that matches "AB" and applies addresses with both
>>>> domains.
>>>>
>>>>> 2) Have 3 more domain users who need only domainB.com email
>>>>
>>>> That second-highest priority could match "B" in extension attribute 10.
>>>>
>>>>> 3) Everyone else only has domainA.com email
>>>>
>>>> This would be your lowest priority policy that matches all recipients.
>>>>
>>>>>
>>>>> Article
http://support.microsoft.com/kb/289833/en-us states under the
>>>>> step 11 note, "You may not want every user to have the secondary
>>>>> e-mail address. If you click No, you must create another recipient
>>>>> policy for those specific users who need this addresses, or manually
>>>>> add the address for each user." I don't get the part about "...or
>>>>> manually add the address for each user."
>>>>
>>>> I think the approach I just gave you makes this moot.
>>>>
>>>>> All 25 users are on one SBS domain, as they need access to resources
>>>>> on the SBS server. Some of them work for a sister company, hence the
>>>>> need for the second domain email. For the sister company, they
>>>>> currently use their web host for domainB.com to do their email and
>>>>> they POP it into Outlook. I want everything in Exchange.
>>>>>
>>>>> As far as the MX record for domainB.com, if I understand this article
>>>>> to be correct
http://www.msexchange.org/tutorials/MF010.html, then the
>>>>> MX record for domainB.com should be the same MX as domainA.com
>>>>> (mail.domainA.com) so that PTR records (and the mail server greeting,
>>>>> if it matters) work properly. Or should I have a mail.domainB.com MX
>>>>> record with its corresponding A record pointing to the SBS server IP
>>>>> address?
>>>>
>>>> Two MX records both pointing to one A record is just fine.
>>>>
>>>>> What are the functional differences between the two methods (both
>>>>> domains in default policy, or two separate policies)?
>>>>
>>>> Follow my approach for best results.
>>>>
>>>>> I can think of the following:
>>>>>
>>>>> 1) If the second domain is added to the default policy, then ALL
>>>>> domain users get the second domain address as well, correct?
>>>>
>>>> Remember that only the highest matching policy applies. So the
>>>> approach I suggest should be foolproof.
>>>>
>>>>> 2) If a separate recipient policy is used, then I could choose
>>>>> specific users to get the second domain, correct?
>>>>
>>>> Yes, like I described.
>>>>
>>>>> Thank you!
>>>>
>>>> Happy to have helped.
>>>>
>>>>> Gregg Hill
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>