Had an interesting issue the other day;
Installing a new 3-node Multi-Role Exchange 2010 deployment – like so;
(for reference, the CAS array will be fronted by a Hardware box provided by the customer – probably a NetScaler or something similar)
Each of the servers was installed – each created the default “Mailbox 00915125” style databases.
Now, typically I rename and move the EDB/Log location for these – it always seems simpler than moving the System-type mailboxes that are located on the first 2010 mailbox database in an organisation. I did so again in this instance, renaming them and moving them to the Mount points created similar to below;
All seemed to be going well – so I created the 3-node DAG (placing the inactive FSW on the vCentre server for later use) and now its time to create myself a secondary copy of one of the six databases.
I ran the usual “add Mailbox database copy” EMC wizard, selecting the second server as a target for a copy of “DB1”. However it copied over the initial EDB file, but wouldn’t copy over any logs (and therefore sat at ~30 logs to copy/replay).
Event log had one error message;
The internal database copy (for seeding or analysis purposes) has been stopped because it was halted by the client or because the connection with the client failed.
Helpful. A Google search turned up This Link – and yes indeed I have SnapManager for Exchange installed (this is a NetApp based deployment after all) – however I am past the version noted (in fact am running the latest 6.0.2.x revision) – and cannot see anything on the NetApp NOW portal regarding this error.
Regardless I removed SME – no joy.
I then tried seeding a second database (after removing the DB1 copy) – and found that out of my 6 databases three wouldn’t seed;
DB1 – formally the default MDB on SERVER01
DB3 – formally the default MDB on SERVER02
DB5 – formally the default MDB on SERVER03
Strange to see but a very clear pattern. So I deleted DB1 and recreated it (initially as DB1 – however this then seemed to inherit the same MailboxDatbaseCopy object in AD so it still didn’t work so I recreated it) as MDB1 and voila it seeded. Even after renaming it back to “DB1” it caught back up (and I tested it for failure heavily later on – note to self btw – do NOT delete the boot disks from the vSphere server on an Exchange 2010 deployment. They do come back – but its not pretty and makes you sweat!).
So in short, if you are having problems seeding a Database to a second node, and it is the default created with Exchange 2010 SP1 – delete and try again.
(For reference these servers were installed with 2010 SP1 and then updated with RU3 v 3)
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?