Just a quick one – as the title Suggests Microsoft recently pulled RU4 for Exchange 2010 SP1 due to a new-found bug.
The current answer is one of two things;
1) Uninstall RU4
2) Apply the Interim patch for RU4 (KB 2581545). You will have to ring Microsoft for this (as it is not yet published) – however be warned that initially this KB number will not seem to exist. Best bet is to raise a call with the Exchange team (you will have this refunded as it is a bug/fix situation) – however I had to get to third-line Exchange guys before I got an “Yes, it’s here”. Also bear in mind that this will likely have to be removed before RU5 can be applied (when it is released).
(For my own sanity I posted this as a comment ;
Recently had the following error when testing ActiveSync (via www.testexchangeconnectivity.com after the IT manager said their Android device wouldn’t work )
I did a bit of digging and found out something I did not know – if you are a member of any BUILTIN Administrative group in Active Directory then you cannot utilised ActiveSync!! (This is due to the “Inherit permissions” removing as you are a member of a “Protected Group” from what I could gather).
Oh well, time to remind people that they should not be using Domain Administrative accounts for day-to-day access!!!
If you get the following error;
Ensure that the “Autodiscover.domain.com” public name is added to the TMG rule that has the /Autodiscover/ Path – IT DOESNT GET ADDED BY DEFAULT! ;
To customise the Login page (say, removing the “DOMAIN\” part of the username prompt) edit the “strings.txt” found in ;
C:\Program Files\Microsoft Forefront Threat Management Gateway\Templates\CookieAuthTemplates\Exchange\HTML
Look for the string;
And change it to be what’s required (the above has the DOMAIN\ already removed).
Any of these strings can be changed.
To force changes to take effect, restart the TMG Firewall Service
Quite often I will enable HTTP (i.e. disable the SSL requirement of IIS 7.5 in 2008 R2) access within IIS to allow me to do a neat HTTP to HTTPS redirect on the root folder.
This allows silly users to do the old “webmail.domain.com” syntax in their browser of choice and still get them to the /owa virtual directory.
However when you go to assign a certificate to this using EMC a warning is flagged;
Do you want to enforce SSL communication on the root web site? If not, rerun the cmdlet with the –DoNotRequireSSL parameter.
I clicked “no” (obviously) and the EMC process completed Successfully – i.e. with a nice big fat green tick
However upon further inspection it appeared that it hadn’t completed – in fact the certificate hadn’t applied at all.
Running it from the EMS with the –DoNotRequireSSL parameter sorted me out, but surely if you answer no and therefore exit out of the process it should pass through an error output rather than a success?
Has a fab little script that will generate you a PS1 script to automate the mailbox count over multiple databases.
It only works with count so far – but the author says they will eventually re-write it to count size distribution also.
Handy as hell when mass-provisioning mailboxes using, oh I don’t know, Quest tools.