Exchange Ignoring Configs?

Exchange Version: 2010 (14.03.0158.001)
Server version: Windows Server 2012

Exchange seems to be ignoring the settings and setup in the server. Here's an example:

Despite having "Send As" permissions, the user Ava cannot send as the user George:

Sendas
Here's where it tells me "no". This is consistent from the web interface (remotely) as well as from outlook (locally), even after doing gpudate /force on the client machine.

Computer says "no"
How to fix this?

Sidenote: there appear to be other items where this permission problem is showing up. One user is having a hard time sharing their calendar, and network wide, exchange seems to be ignoring the max allowed attachment size. it's liket he settings are not getting updated somewhere...
LVL 32
DrDamnitAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

AmitIT ArchitectCommented:
download OAB on client side and test again.
0
tshearonCommented:
What version of Exchange are you running? Did you just recently update a service pack or a rollup update?
0
MHMAdminsCommented:
Do you use cached exchange mode? Try turning that option off and see if it works then.
0
Newly released Acronis True Image 2019

In announcing the release of the 15th Anniversary Edition of Acronis True Image 2019, the company revealed that its artificial intelligence-based anti-ransomware technology – stopped more than 200,000 ransomware attacks on 150,000 customers last year.

tshearonCommented:
Sorry I see your version. Did you just perform any updates?
0
DrDamnitAuthor Commented:
@MHMAdmins:
Cached mode does not apply to OWA. and No, we're not using it on the client in question.

@tshearon
Nothing more than normal Windows Update updates... but this has been going on for the better part of a week. The symptoms are non-emergent, but it needs to be fixed.
0
DrDamnitAuthor Commented:
@amit:

How do I download OAB on client side and retry?
0
MHMAdminsCommented:
Any major flags being thrown in the event viewer for microsoft exchange?
0
DrDamnitAuthor Commented:
@amit:

I see the cmdlets to re-download the OAB here. What's throwing me off is that OWA is having the same problem, which should be independent of the OAB download on the Outlook client. Right?
0
DrDamnitAuthor Commented:
@MHMAdmins: nothing glaring... let me clear out the logs, and retry so that it is cleaner...
0
AmitIT ArchitectCommented:
You download OAB on client end system via outlook.
0
MHMAdminsCommented:
Also did you set the permissions with the EMC or through powershell? I've noticed sometimes you have to run certain things in powershell for it to effect correctly.
0
DrDamnitAuthor Commented:
Set permissions from EMC. I'll try again via powershell...
0
tshearonCommented:
Remove the permissions first. Removing and re-adding will likely restore the access but we also want to resolve the issue entirely. Their is likely a cause.
0
DrDamnitAuthor Commented:
I am starting to think this is realted to this other item I've been chasing for a while...

http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_28524795.html

Thoughts?
0
tigermattCommented:
The Offline Address Book has nothing to do with this, nor does Group Policy, nor does Cached Exchange Mode (since this is OWA, not Outlook-related). If the permissions are set via the management console, removing and re-adding unfortunately is unlikely to be a fix, either -- unless there's a very complex multi-site AD setup going on here, the console won't be lying.

I highly suspect you are being caught out by Exchange's internal cache of Active Directory data. Send-As permissions are actually stored on the relevant principal's object in Active Directory; Exchange caches these data for a period of up to 2 hours to avoid load on domain controllers. Probably not a concern for you, but definitely an issue in high volume environments.

Two solutions:

1. Wait for the cache to be purged, then try again.
2. Restart the information store and associated Exchange services on the machine, which will force the cache to be flushed.

You should also be careful if any of the accounts you are using in this send-as relationship are members of "privileged" groups in Active Directory, including anything in the "Built-in" container (Administrators, Backup Operators, Print Operators, etc.) and any of the higher privilege domain-level groups (Domain Admins, Enterprise Admins, etc.). Members of such groups have more stringent permissions forced upon them.  The ACL model should cause an explicit allow (this Send-As right) to override an inherited deny (inherited from elsewhere in AD). However, if this caveat applies, I would recommend simplifying the setup and layering the complexity on step-by-step until you find the problem. (Restarting the services each time to ensure the cache is cleared.)
0
DrDamnitAuthor Commented:
@tigermatt:

I agree with your assessment that the OAB and other suggestions are not relevant because the symptoms occur in OWA as well.

I had to wait until the system was idle, and finally restarted the Active Directory Topology service (because it restarts nearly everything else), but the problem persists.

Since this server needed the most recent schannel patch, I ran the updates, and rebooted the server, but I still have the same problem.

Doesn't appear to be cache now...

Thoughts?
0
Simon Butler (Sembee)ConsultantCommented:
Those permissions look completely wrong.
Security Principle shouldn't be listed there, neither should "Everyone".

Is the user concerned a member of a protected group? Domain Admins, Power Users etc? Members of those groups have an deny permission which overrides any other permission.

However considering the other problems with the permissions, it could be that the permission structure is completely broken.

Simon.
0
DrDamnitAuthor Commented:
@Simon

"Everyone" was added temporarily as a debugging measure. It has since been removed, but good eye for catching that.

The user is NOT a member of a protected group. They are part of an OU that is for people who are physically in the office, and that OU is not a protected group.

They are just a regular user.
0
DrDamnitAuthor Commented:
@Simon:

If the permissions structure was broken, how would we fix it?
0
AmitIT ArchitectCommented:
0
DrDamnitAuthor Commented:
Latest roll up fixed this problem. It was an Exchange internal issue I guess.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.