The properties on have invalid data. If you click OK, default values will be used..

A customer had a user with a mailbox throwing the following error whenever they tried to change a value:

The properties on [recipient] have invalid data. If you click OK, default values will be used instead and will be saved if you do not change them before hitting Apply or OK on the property page. If you click cancel, the object will be displayed read-only and corrupted values will be retained.

OK no problem, I'll just go in and get rid of anything that doesn't look right...wrong. The console wouldn't let me save the settings.

Apparently the storage quotas were such that the Prohibit Send Limit value was less than the Warning Limit. I was, however, unable to modify it in ADUC/DSA or in the EMC.

I attempted to change the value in EMS, but it threw the exact same error.

When finesse isn't enough, brute force wins. I popped open adsiedit.msc by launching adsiedit.msc from 'Run,' then navigated to where the user resided under Domain -> User OU, right clicked, and clicked properties. Sure enough the EMC and EMS were lying to me:

I modified the values to what I wanted them to be:

Voila.. Invalid Data errors are gone.

Digicert Intermediate Cert Eclipsed by Root - ActiveSync issues

We recently ran into an issue where using a new Digicert certificate essentially broke activesync for most people in the company. The issue is that the new root certificate for Digicert isn't compatible with older browsers and devices (they don't come standard with the new root certs for Digicert like they might with Verisign and others). The primary phone of the organization was a Motorola Q, which made the issue quite visible.

The problem boiled down to this root cert taking precedence over the intermediate cert (Digicert calls it eclipsing which I suppose is a more valid term), which would have worked fine. After the Digicert Root Cert was removed, the issue was resolved.

Note: Be sure that the intermediate is in place and functioning or else you will break all of the modern phones and browsers as well.

Also as an alternative fix, you could install the root cert on the phones in question. This is more labor intensive, but might be viable if there are only a few old straggler phones floating around.

Reference:

https://www.digicert.com/ssl-support/windows-cross-signed-chain.htm

You can also run a good test for this and other issues at:

https://www.digicert.com/help/

KB968389 LSASS Reboots

Recently we had an issue with an Exchange server constantly rebooting. The symptoms were extremely indicative of virus infection. Terminations of LSASS.exe, timed reboots, and permission revocations, were all occurring, and so we were immediately assuming Sasser/Blaster.

It then began to seemingly cause issues with domain communication. Upon checking the system properties, the domain registered as *Unknown* and it was nearly impossible to perform any action as all permissions had been stripped (we were using a domain account so this sort of made sense).

After having a local tech bounce the box and login with the KVM, the issue seemed resolved for these domain level issues, and we never saw them again. The original LSASS issues and reboots continued, however. Not wanting to waste any more time, we gave PSS a call. They informed us that a patch we had installed, KB968389, was likely causing the issue. Despite passing our patch testing and being installed on numerous other environments, MS told us that they have been informed of other sites experiencing the same issue. Removing the patch resolved the issue.

In summary.. KB968389 = Bad if you like a stable environment