Check out the big brain on Kong!

Coralkong

Coralkong

Alien
I have been dealing with a customer issue for over 2 weeks now.

MS Tech Support could not tell me how to fix this specific problem. Finally, I told the MS guy to fuck off (well, not quite in those terms, but I haven't taken their calls in over a week), because I worked with him every day for a week, and got nowhere. He kept doing the same thing over and over and over until finally on day 5, I blew a gasket.

So.....I have 27,000+ mailboxes that pretty much were "broken". Yep, you read that right....27K+ mailboxes.

So....fuck Microsoft, I wrote a custom script to fix what those douche-nozzles couldn't figure out how to make work.

Now, I am gonna throw this out there:

You may be able to tell me what this does, but $100 to the Jeremy fund if you can tell me EXACTLY what problem this fixes (because MS couldn't figure out how to fix it). In other words, why would you need to run this?

$s = Get-ADUser -SearchBase "ou=sampleOU,dc=sitename,dc=domainname,dc=local" -resultsetsize $null -filter *
$s | foreach {
set-aduser $_.samaccountname -add @{"targetaddress" = $_.samaccountname + "@o365domain"}
}
$s | foreach {
set-aduser $_.samaccountname -add @{"proxyaddresses" = "SMTP:" + $_.samaccountname + "@o365domain"}
}


I am pretty proud of myself, pretty pissed off at MS tech support, but more just happy that this problem is finally fixed. Pretty sure the client is going to be happy as well.

I am exhausted.

And fuck MS tech support in their Meathead faces. Fucktards.
 
It searches for all of the Active Directory users that match "ou=sampleOU,dc=sitename,dc=domainname,dc=local" - which is probably all of them.

It then adds a field called "targetaddress" in each AD user account. "targetaddress" is made up of the account name + "@o365domain"
It then adds a field called "proxyaddress" in each AD user account. "proxyaddress" is made up of "SMTP:" + the account name + "@o365domain"

That, all together, would allow AD authenticated users to be able to access MS' Office 365 service for e-mail.

I'm guessing. Actually, I am interpreting the script and making guesses.

That's really cool.
If I'm right, in HINDSIGHT it's pretty straightforward. The ingenious part is knowing what needs to be tweaked and considering to do it with a script to that many users.
Nice!!!
 
dodgechargerfan said:
It searches for all of the Active Directory users that match "ou=sampleOU,dc=sitename,dc=domainname,dc=local" - which is probably all of them.

It then adds a field called "targetaddress" in each AD user account. "targetaddress" is made up of the account name + "@o365domain"
It then adds a field called "proxyaddress" in each AD user account. "proxyaddress" is made up of "SMTP:" + the account name + "@o365domain"

That, all together, would allow AD authenticated users to be able to access MS' Office 365 service for e-mail.

I'm guessing. Actually, I am interpreting the script and making guesses.

That's really cool.
If I'm right, in HINDSIGHT it's pretty straightforward. The ingenious part is knowing what needs to be tweaked and considering to do it with a script to that many users.
Nice!!!
Click to expand...


You sir, are absolutely correct. Insomuch as that is precisely what it does. :wink:

I will be floored if anyone knows WHY you would need to run it, though.

As a FYI (because you probably want to know.....maybe not, who the fuck knows, Imagunna tell you anwyay), :)

The proxyaddress attribute of your AD acct sets the default REPLY address for your email. By default, O365 adds a @o365domain.onmicrosoft.com to the end of your email address.
By setting the primary SMTP: address, it sets your default reply from address. Thus, if you sent an email to johnny.user@o365domain, and this property was not set, you would get the email, but if you replied, it would show up as johnny.user@o365domain.onmicrosoft.com. (SMTP: is the primary reply address. All aliases are actually listed under the proxyaddress attribute as (lowercase) smtp: addresses).


You would still be able to log in to your O365 acct using your username, no matter what your "SMTP:" address was. That just sets it so that all reply emails FROM your O365 acct show as your claimed domain name vs your O365.onmicrosoft.com domain name.

But you on the right track.

If you really want to know, I will spill the beans, because I will be DAMNED if anyone else has to come up against this and try to figure it out on their own. :)
 
Last edited:
Cool.
That makes sense. Your replyto address could be anything.

I was thinking it might have been a migration from local e-mail servers to Office 365 and MS left out or screwed up the setup.
 
That's good stuff.
I couldn't write that. I don't even know what language you are using.

But with the programming that I've done in the past and working with databases, I can follow along.
 
dodgechargerfan said:
That's good stuff.
I couldn't write that. I don't even know what language you are using.

But with the programming that I've done in the past and working with databases, I can follow along.
Click to expand...

It was a bitch to figure out, and when you finally hear what was going on....you'll freak.

The cmd/script is run from the AD module of PowerShell (which is completely different than the Exchange PS module). :rolleyes: Even the cmds are different.

It was not easy to come up with.....so, thank you.
:)
 
OK,,,,so here's the WHY.

On-premise Exchange2010 setup.
O365 setup. Connectors are in place (Hybrid config) between on-premise and O365. User accounts (and properties) are Synced up to O365 every 4 hours.

Thus, changes made to on-premise AD accts sync up to O365.

On premise Exchange (email) accounts are in and use a @maindomainname.com account.
O365 users are using a @sub.maindomainname.com account. ONLY these user accts are synced up to O365. These are in a child domain in AD.
The child domain is set to use username@sub.maindomainname.com to log on locally. Meaning, inside the network, they log on as johnny.user@sub.maindomainname.com.
They go home and log into O365 (email) using johnny.user@sub.maindomainname.com.


ISSUE:
Users at @maindomainname.com (on-premise) are NOT able to send email to the sync'ed users at @sub.maindomainname.com (O365 users).
Users at @maindomainname.com (on-premise) CAN send email to the sync'ed users using @o365domainname.onmicrosoft.com.
If you or I send an email to @sube.maindomainname.com, the user gets it and can return it, no issues. Issue only exists from internal to O365.
Cannot "remote mailbox enable" users in the child domain (the O365 synced accts), because it appeneds a @maindomainname.com email address. If the email gets replied to, the on-site spam filter automatically detects the account and adds it. This will result in a license issue.

THUS:

internal users cannot send to the sub.maindomainname.com acct.
Because the users in the child domain are using username@sub.maindomainname.com to log in LOCALLY to the network, Exchange sees that domain as an INTERNAL only domain.
Setting the primary SMTP address (the default address) to @sub.maindomainname.com, causes email to hang in the Exchange server in an "Unreachable domain" state.
However, if the primary SMTP address (default address) is NOT set for the user, email will flow from internal to @sub.maindomainname.com, but reply emails appear to come from the @o365.onmicrosoft.com address.

THEREFORE:

First, let me state, MS tech support can eat a bowl of dicks. Ok...moving on.
We tried everything. I tried everything.

Then I stumbled upon the answer.

By setting the "targetaddress" attribute in AD (using ADSIedit, or bulk doing it by the script above), it sets the routing address to point to "$variable.username@o365.com".
Exchange 2010 will NOT see/recognize the fact that the child domain is NOT part of the maindomainname.com unless this attribute is set.
Meaning, Exchange will want to deliver sub.maindomainname.com LOCALLY, unless THIS (and ONLY this) attribute gets set. None of the other BS attributes matter.


SO:

by setting these settings, I fix all user reply from addresses.
I bypass the spam filter license limitations
I allow email to and from on-premise to O365 users in a child domain being sync'ed up using DirSync.
All users should now be fixed.


I am exhausted.
 
Programming thread, noice.

I learned a little this year, don't think I could ever do it for a living though. Maybe for game development one day.
 
You must log in or register to reply here.
Back
Top