Fab article to help troubleshoot those “client running slow” issues
though in 99% of the time, it’s either;
1) Users in Online mode (High RPC request latency/queue length)
2) Lack of disk spindles / IOPS for DB/Log drives (disk queue length will determine this)
3) Users in Online mode 😉
Allows you to specify recipitent email, sender email and SMTP server to check connectivity.
Also gives you diagnostic TELNET walkthrough so you can see where it is failing (if it is).
Very handy 🙂
Here has some interesting info regarding OAB and 0x8004010F errors 🙂
Having problems getting PF’s replicated (or moved) between 2003 and 2007?
KB 830181 suggests a fix for Exchange 5.5 / 2000 to 2003.
However, I have it on good advice (Thanks Mr Chandra) that this method can also fix any “sticking” folders in 2003 –> 2007. Only difference is that instead of restaring the MSExchangeTransport service, you have to bounce the box.
Mr Chandra also suggested you place this on the receiving server.
Worth a go for the sake of a reboot.
Customer emails through their Exchange event logs, and you need to read through them.
You *could* move them onto your Exchange box and view them there, but what if you couldnt access the box? What if it was a different version? What if you didn’t want to?
You can view other log types by using the /auxsource flag. Handy 🙂
Come across a semi-interesting “bug” / “feature” this morning in Server 2003 SBS. Old product, I know, but meh who cares.
If you create a new user with the SBS Wizard, whilst you have a Recovery Storage Group configured (even if it is offline), it will default to creating (or attempting to as you will see) the users Exchange box on that SG.
As you try to login as the new user, you will obviously get “unable to access mail folder”, as the SG is (or should) be offline. Viewing the User properties will also show that they are in fact stored in the RSG rather than your First Storage Group.
Fix is easy enough, and comes in two flavours. Hardcore or Wussy.
Remove the user you just created. Remove the RSG. Re-create the user. Check s/he is on the FSG. Voila.
Open up ADSI Edit.
Locate the user object, then locate the homeMDB string. Edit, and replace;
Recovery Storage Group
First Storage Group
Save, exit, and re-login as user. (Then go delete your RSG).
Personally I prefer the latter, as I always like to ADSI M$’s “features”