When the AD attribute TargetAddress is synchronised to Office 365, where does it “go”?Office 365 NTLM authenticationDoes Office 365 Small Business Pro support multiple domains?Review spam messages in Office 365Authenticating local Office apps with Office 365Limiting Office 365 logins to our domainOffice 365 DLP Incident ReportsHow do I keep on running Office 365 Business Premium 2013 when the Office 2016 upgrade goes live?Office 365 alias does not accept external emailsOffice 365 - report to find instances of emails sent directly to Office 365, bypassing spam filter?Powershell commands applicable to Exchange Online in O365 Hybrid Environment
Syntax and semantics of XDV commands (XeTeX)
How did Gollum enter Moria?
Is there a name for the trope when there is a moments dialogue when someone pauses just before they leave the room?
Cut the gold chain
Dmesg full of I/O errors, smart ok, four disks affected
How does DC work with natural 20?
Non-misogynistic way to say “asshole”?
Where should a runway for a spaceplane be located?
Extending prime numbers digit by digit while retaining primality
Definition of 'vrit'
Why is "Congress shall have power to enforce this article by appropriate legislation" necessary?
Methodology: Writing unit tests for another developer
Find All Possible Unique Combinations of Letters in a Word
Why don't countries like Japan just print more money?
Draw a symmetric alien head
How do internally carried IR missiles acquire a lock?
How hard is it to distinguish between remote access to a virtual machine vs a piece of hardware?
What is the meaning of "понаехать"?
Why don't we have a weaning party like Avraham did?
Improve appearance of the table in Latex
How do I see debug logs for Change Data Capture triggers in Salesforce?
Justifying Affordable Bespoke Spaceships
Rejecting an offer after accepting it just 10 days from date of joining
Why isn't it a compile-time error to return a nullptr as a std::string?
When the AD attribute TargetAddress is synchronised to Office 365, where does it “go”?
Office 365 NTLM authenticationDoes Office 365 Small Business Pro support multiple domains?Review spam messages in Office 365Authenticating local Office apps with Office 365Limiting Office 365 logins to our domainOffice 365 DLP Incident ReportsHow do I keep on running Office 365 Business Premium 2013 when the Office 2016 upgrade goes live?Office 365 alias does not accept external emailsOffice 365 - report to find instances of emails sent directly to Office 365, bypassing spam filter?Powershell commands applicable to Exchange Online in O365 Hybrid Environment
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
When I set the TargetAddress in an on-premise environment, I'm able to enable cross domain free/busy lookups in a hybrid cloud environment. In addition, email is forwarded to the TargetAddress, and the envelope/P1 header is rewritten accordingly.
However, I am unable to locate this attribute in any of the Powershell commands for the respective environments (O365, EOP, Exchange, AzureAD).
Where can I find this attribute in the hosted environment, because some aspect of it is present, and affecting email.
microsoft-office-365
add a comment |
When I set the TargetAddress in an on-premise environment, I'm able to enable cross domain free/busy lookups in a hybrid cloud environment. In addition, email is forwarded to the TargetAddress, and the envelope/P1 header is rewritten accordingly.
However, I am unable to locate this attribute in any of the Powershell commands for the respective environments (O365, EOP, Exchange, AzureAD).
Where can I find this attribute in the hosted environment, because some aspect of it is present, and affecting email.
microsoft-office-365
(Get-ADUser UserID -Properties TargetAddress).TargetAddress
– EBGreen
Jul 10 '18 at 17:45
@ebgreen that command is for an onpremise user right? I'm trying to locate the same via AzureAD, Exchange, or O365/MSOL commandlets.
– Ran Dom
Jul 10 '18 at 18:35
Does Get-AzureADUser get it for you?
– EBGreen
Jul 10 '18 at 18:44
@EBGreen It doesn't seem that a -Properties (or anything like it) exists in the AzureAD commandlet. I tried to dump an object with -Format-List and returned a smaller subset of attributes than what's available in Get-mailbox, other than some provisioning attributes.
– Ran Dom
Jul 10 '18 at 19:08
add a comment |
When I set the TargetAddress in an on-premise environment, I'm able to enable cross domain free/busy lookups in a hybrid cloud environment. In addition, email is forwarded to the TargetAddress, and the envelope/P1 header is rewritten accordingly.
However, I am unable to locate this attribute in any of the Powershell commands for the respective environments (O365, EOP, Exchange, AzureAD).
Where can I find this attribute in the hosted environment, because some aspect of it is present, and affecting email.
microsoft-office-365
When I set the TargetAddress in an on-premise environment, I'm able to enable cross domain free/busy lookups in a hybrid cloud environment. In addition, email is forwarded to the TargetAddress, and the envelope/P1 header is rewritten accordingly.
However, I am unable to locate this attribute in any of the Powershell commands for the respective environments (O365, EOP, Exchange, AzureAD).
Where can I find this attribute in the hosted environment, because some aspect of it is present, and affecting email.
microsoft-office-365
microsoft-office-365
edited Jul 10 '18 at 17:43
Ran Dom
asked Jul 10 '18 at 17:34
Ran DomRan Dom
2615
2615
(Get-ADUser UserID -Properties TargetAddress).TargetAddress
– EBGreen
Jul 10 '18 at 17:45
@ebgreen that command is for an onpremise user right? I'm trying to locate the same via AzureAD, Exchange, or O365/MSOL commandlets.
– Ran Dom
Jul 10 '18 at 18:35
Does Get-AzureADUser get it for you?
– EBGreen
Jul 10 '18 at 18:44
@EBGreen It doesn't seem that a -Properties (or anything like it) exists in the AzureAD commandlet. I tried to dump an object with -Format-List and returned a smaller subset of attributes than what's available in Get-mailbox, other than some provisioning attributes.
– Ran Dom
Jul 10 '18 at 19:08
add a comment |
(Get-ADUser UserID -Properties TargetAddress).TargetAddress
– EBGreen
Jul 10 '18 at 17:45
@ebgreen that command is for an onpremise user right? I'm trying to locate the same via AzureAD, Exchange, or O365/MSOL commandlets.
– Ran Dom
Jul 10 '18 at 18:35
Does Get-AzureADUser get it for you?
– EBGreen
Jul 10 '18 at 18:44
@EBGreen It doesn't seem that a -Properties (or anything like it) exists in the AzureAD commandlet. I tried to dump an object with -Format-List and returned a smaller subset of attributes than what's available in Get-mailbox, other than some provisioning attributes.
– Ran Dom
Jul 10 '18 at 19:08
(Get-ADUser UserID -Properties TargetAddress).TargetAddress
– EBGreen
Jul 10 '18 at 17:45
(Get-ADUser UserID -Properties TargetAddress).TargetAddress
– EBGreen
Jul 10 '18 at 17:45
@ebgreen that command is for an onpremise user right? I'm trying to locate the same via AzureAD, Exchange, or O365/MSOL commandlets.
– Ran Dom
Jul 10 '18 at 18:35
@ebgreen that command is for an onpremise user right? I'm trying to locate the same via AzureAD, Exchange, or O365/MSOL commandlets.
– Ran Dom
Jul 10 '18 at 18:35
Does Get-AzureADUser get it for you?
– EBGreen
Jul 10 '18 at 18:44
Does Get-AzureADUser get it for you?
– EBGreen
Jul 10 '18 at 18:44
@EBGreen It doesn't seem that a -Properties (or anything like it) exists in the AzureAD commandlet. I tried to dump an object with -Format-List and returned a smaller subset of attributes than what's available in Get-mailbox, other than some provisioning attributes.
– Ran Dom
Jul 10 '18 at 19:08
@EBGreen It doesn't seem that a -Properties (or anything like it) exists in the AzureAD commandlet. I tried to dump an object with -Format-List and returned a smaller subset of attributes than what's available in Get-mailbox, other than some provisioning attributes.
– Ran Dom
Jul 10 '18 at 19:08
add a comment |
1 Answer
1
active
oldest
votes
The TargetAddress attribute does not get synced, it is on-premises only.
The reason for this is that there is no reason to actually sync it.
It is used for the following:
You have migrated a user from On-Prem to Office 365 or you have created a remote mailbox user on-premises that has a mailbox in Office 365.
The user is synced to Office 365 and the mailbox lives in Exchange Online.
Now, since Exchange is self aware, it will need an object locally to tell it where the user is to be found.
The Target Address says, for this remote user, send mail to this address, the mail then goes through the normal connector mailflow in your hybrid setup and lands in Office 365 where the mail is delivered as normal since it has been sent redirected to the address the user has in Office 365.
Usually for Target Address you would use the mail.onmicrosoft.com domain alias for the user, your on-prem connector points this domain to Office 365.
As soon as the mail lands in Office 365 the mail alias (proxyaddress) will tell Exchange Online where the mailbox is. This is why Office 365 doesn't need to know the Target Address attribute, all is handled by normal mailflow, it is only for On-Prem to know what to do since the mailbox is not in the local Exchange Organisation.
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address tosmtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts
– Ran Dom
Jul 25 '18 at 20:59
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f920344%2fwhen-the-ad-attribute-targetaddress-is-synchronised-to-office-365-where-does-it%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The TargetAddress attribute does not get synced, it is on-premises only.
The reason for this is that there is no reason to actually sync it.
It is used for the following:
You have migrated a user from On-Prem to Office 365 or you have created a remote mailbox user on-premises that has a mailbox in Office 365.
The user is synced to Office 365 and the mailbox lives in Exchange Online.
Now, since Exchange is self aware, it will need an object locally to tell it where the user is to be found.
The Target Address says, for this remote user, send mail to this address, the mail then goes through the normal connector mailflow in your hybrid setup and lands in Office 365 where the mail is delivered as normal since it has been sent redirected to the address the user has in Office 365.
Usually for Target Address you would use the mail.onmicrosoft.com domain alias for the user, your on-prem connector points this domain to Office 365.
As soon as the mail lands in Office 365 the mail alias (proxyaddress) will tell Exchange Online where the mailbox is. This is why Office 365 doesn't need to know the Target Address attribute, all is handled by normal mailflow, it is only for On-Prem to know what to do since the mailbox is not in the local Exchange Organisation.
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address tosmtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts
– Ran Dom
Jul 25 '18 at 20:59
add a comment |
The TargetAddress attribute does not get synced, it is on-premises only.
The reason for this is that there is no reason to actually sync it.
It is used for the following:
You have migrated a user from On-Prem to Office 365 or you have created a remote mailbox user on-premises that has a mailbox in Office 365.
The user is synced to Office 365 and the mailbox lives in Exchange Online.
Now, since Exchange is self aware, it will need an object locally to tell it where the user is to be found.
The Target Address says, for this remote user, send mail to this address, the mail then goes through the normal connector mailflow in your hybrid setup and lands in Office 365 where the mail is delivered as normal since it has been sent redirected to the address the user has in Office 365.
Usually for Target Address you would use the mail.onmicrosoft.com domain alias for the user, your on-prem connector points this domain to Office 365.
As soon as the mail lands in Office 365 the mail alias (proxyaddress) will tell Exchange Online where the mailbox is. This is why Office 365 doesn't need to know the Target Address attribute, all is handled by normal mailflow, it is only for On-Prem to know what to do since the mailbox is not in the local Exchange Organisation.
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address tosmtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts
– Ran Dom
Jul 25 '18 at 20:59
add a comment |
The TargetAddress attribute does not get synced, it is on-premises only.
The reason for this is that there is no reason to actually sync it.
It is used for the following:
You have migrated a user from On-Prem to Office 365 or you have created a remote mailbox user on-premises that has a mailbox in Office 365.
The user is synced to Office 365 and the mailbox lives in Exchange Online.
Now, since Exchange is self aware, it will need an object locally to tell it where the user is to be found.
The Target Address says, for this remote user, send mail to this address, the mail then goes through the normal connector mailflow in your hybrid setup and lands in Office 365 where the mail is delivered as normal since it has been sent redirected to the address the user has in Office 365.
Usually for Target Address you would use the mail.onmicrosoft.com domain alias for the user, your on-prem connector points this domain to Office 365.
As soon as the mail lands in Office 365 the mail alias (proxyaddress) will tell Exchange Online where the mailbox is. This is why Office 365 doesn't need to know the Target Address attribute, all is handled by normal mailflow, it is only for On-Prem to know what to do since the mailbox is not in the local Exchange Organisation.
The TargetAddress attribute does not get synced, it is on-premises only.
The reason for this is that there is no reason to actually sync it.
It is used for the following:
You have migrated a user from On-Prem to Office 365 or you have created a remote mailbox user on-premises that has a mailbox in Office 365.
The user is synced to Office 365 and the mailbox lives in Exchange Online.
Now, since Exchange is self aware, it will need an object locally to tell it where the user is to be found.
The Target Address says, for this remote user, send mail to this address, the mail then goes through the normal connector mailflow in your hybrid setup and lands in Office 365 where the mail is delivered as normal since it has been sent redirected to the address the user has in Office 365.
Usually for Target Address you would use the mail.onmicrosoft.com domain alias for the user, your on-prem connector points this domain to Office 365.
As soon as the mail lands in Office 365 the mail alias (proxyaddress) will tell Exchange Online where the mailbox is. This is why Office 365 doesn't need to know the Target Address attribute, all is handled by normal mailflow, it is only for On-Prem to know what to do since the mailbox is not in the local Exchange Organisation.
answered Jul 25 '18 at 11:04
Henrik Stanley MortensenHenrik Stanley Mortensen
2887
2887
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address tosmtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts
– Ran Dom
Jul 25 '18 at 20:59
add a comment |
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address tosmtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts
– Ran Dom
Jul 25 '18 at 20:59
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address to
smtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts– Ran Dom
Jul 25 '18 at 20:59
Based on my experience and testing, I can do something that implies not only that the target address is not only synchronized, but is also acted upon uniquely by the transport agent / EOP. Simply set the target address to
smtp:user@anydomain.com
(not onmicrosoft.com) and send the user a message. The result is that the envelope is rewritten and the message is forwarded by "the cloud" to the external system. I'm aware this isn't standard usage, but its in use by several large enterprises to accommodate a migration from gmail, or other non MSFT systems without having to import contacts– Ran Dom
Jul 25 '18 at 20:59
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f920344%2fwhen-the-ad-attribute-targetaddress-is-synchronised-to-office-365-where-does-it%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
(Get-ADUser UserID -Properties TargetAddress).TargetAddress
– EBGreen
Jul 10 '18 at 17:45
@ebgreen that command is for an onpremise user right? I'm trying to locate the same via AzureAD, Exchange, or O365/MSOL commandlets.
– Ran Dom
Jul 10 '18 at 18:35
Does Get-AzureADUser get it for you?
– EBGreen
Jul 10 '18 at 18:44
@EBGreen It doesn't seem that a -Properties (or anything like it) exists in the AzureAD commandlet. I tried to dump an object with -Format-List and returned a smaller subset of attributes than what's available in Get-mailbox, other than some provisioning attributes.
– Ran Dom
Jul 10 '18 at 19:08