I'm sure all of us implementing OpsMgr can't wait for SP1 to arrive. There's been so many promises, especially wrt the speed of the UI and a number of other quirks (bugs?) that we hope will be fixed. Seems first week of November is the target date, as this blog by Clive Eastwood indicates.
I'll gladly kiss the dev team's feet for this one! Bring it on!
Friday, November 2, 2007
Thursday, November 1, 2007
Configure Mail Flow Monitoring in Exchange 2003
Configuring Mail Flow monitoring is a little bit of a mission, but the instructions are pretty clear, and as long as one sticks to it, all should be OK. I am not going to repeat all the steps here, but I post some links that may be helpful. This is looking at using the OpsMgr 2007 MP. Just some pointers:
-> Use the latest version of the Exchange 2003 MP Wizard (currently 06.05.7903, and is a prereq for OpsMgr 2007 monitoring); trust me, it is more stable.
-> Pre-configure the Mailbox access account and the mailbox accounts. The release notes seem to suggest that running the wizard will take care of this, but this is not (always?) the case. Take special care to perform all the tasks as a Full Exchange Admin.
-> If you are managing geographically dispersed sites, provide some time for all the information to replicate in AD. It goes without saying that your site replications are working correctly (Check it!)
-> Before you run the wizard, send mail to the test mailboxes to ensure "normal" messaging is working OK.
-> I don't particularly think you need to have a test mailbox for each store, but if you do want to remember to name the mailbox "<servername>MOM#" where # can be any number or word.
-> Save your config file after you ran the wizard...and save some time later.
-> If you have some time on hands, I suggest not enabling the "Mail Flow" until you are sure all the other components work. You should see the following events on *all* your configured servers if all goes OK:
* EventId: 19998 - MAPI logon verification : No unexpected exceptions
* EventId: 19980 - MAPI logon verification : All attempted logins of test mailboxes residing on this server succeed
* EventId: 19950 - Exchange MOM : All Mailbox and Public Folder Stores are mounted
* EventId: 19960 - Check service(s) state : All specified services are running
* EventId: 19016 - Exchange MOM - MailFlow : No unexpected exceptions
* EventId: 19556 - Exchange MOM - MailFlow : All mail flow destination addresses were resolved without problems
* EventId: 19554 - Exchange MOM - MailFlow : All expected messages received successfully
-> Once again, be patient, note any errors/warnings on all servers before starting all over again.
-> If you do want to start from scratch (as in deleting all the test mailboxes), ensure the user and mailbox is deleted (and purged), and check for lingering objects in HKLM\SOFTWARE\Microsoft\Exchange MOM.
-> The main issue is to ensure permissions on the test mailboxes are correct (esp post E2K3 SP2!). Mail flow monitoring will not work if this is not correct... Also, it might seem strange, but you disable the Mailbox test users (works fine for me).
-> Although you can run the wizard on one server to configure all the others, I like to run config separately for front-end servers. The reason: services monitored on FE's are not the same as BE, so you get unnecessary alerts when the scripts start looking for a IS service on the FE's
-> There are some specific caveats wrt monitoring OWA/OMA/EAS on FE servers, but I will blog on that later on.
Enough said...some good info on these sites:
Exchange Server Management Pack Guide for MOM 2005
Managing Exchange 2003 With MOM 2005
Creating a MOM test Mailbox
Top Three Configuration Issues with Exchange Management Pack
-> Use the latest version of the Exchange 2003 MP Wizard (currently 06.05.7903, and is a prereq for OpsMgr 2007 monitoring); trust me, it is more stable.
-> Pre-configure the Mailbox access account and the mailbox accounts. The release notes seem to suggest that running the wizard will take care of this, but this is not (always?) the case. Take special care to perform all the tasks as a Full Exchange Admin.
-> If you are managing geographically dispersed sites, provide some time for all the information to replicate in AD. It goes without saying that your site replications are working correctly (Check it!)
-> Before you run the wizard, send mail to the test mailboxes to ensure "normal" messaging is working OK.
-> I don't particularly think you need to have a test mailbox for each store, but if you do want to remember to name the mailbox "<servername>MOM#" where # can be any number or word.
-> Save your config file after you ran the wizard...and save some time later.
-> If you have some time on hands, I suggest not enabling the "Mail Flow" until you are sure all the other components work. You should see the following events on *all* your configured servers if all goes OK:
* EventId: 19998 - MAPI logon verification : No unexpected exceptions
* EventId: 19980 - MAPI logon verification : All attempted logins of test mailboxes residing on this server succeed
* EventId: 19950 - Exchange MOM : All Mailbox and Public Folder Stores are mounted
* EventId: 19960 - Check service(s) state : All specified services are running
* EventId: 19016 - Exchange MOM - MailFlow : No unexpected exceptions
* EventId: 19556 - Exchange MOM - MailFlow : All mail flow destination addresses were resolved without problems
* EventId: 19554 - Exchange MOM - MailFlow : All expected messages received successfully
-> Once again, be patient, note any errors/warnings on all servers before starting all over again.
-> If you do want to start from scratch (as in deleting all the test mailboxes), ensure the user and mailbox is deleted (and purged), and check for lingering objects in HKLM\SOFTWARE\Microsoft\Exchange MOM.
-> The main issue is to ensure permissions on the test mailboxes are correct (esp post E2K3 SP2!). Mail flow monitoring will not work if this is not correct... Also, it might seem strange, but you disable the Mailbox test users (works fine for me).
-> Although you can run the wizard on one server to configure all the others, I like to run config separately for front-end servers. The reason: services monitored on FE's are not the same as BE, so you get unnecessary alerts when the scripts start looking for a IS service on the FE's
-> There are some specific caveats wrt monitoring OWA/OMA/EAS on FE servers, but I will blog on that later on.
Enough said...some good info on these sites:
Exchange Server Management Pack Guide for MOM 2005
Managing Exchange 2003 With MOM 2005
Creating a MOM test Mailbox
Top Three Configuration Issues with Exchange Management Pack
Wednesday, October 31, 2007
Configuring Exchange Baselines in OpsMgr
This is an example of the type of alert that causes lots of noise in some environments. We run Remote Operations Manager, so I decided to apply this to all the Exchange instances.
OpsMgr Alert: Number of RPC requests is outside the calculated baseline
Monitor Rule: Microsoft.Exchange.ExchangeComponent.IS.RPCRequests
The Number of RPC requests is outside the calculated baseline. The current value is 0.333333333333333
One could of course just ignore it (sure...) or completely disable the rule. I've been looking at two helpful posts (see links below) that seems to provide the answer, painstaking as the process is. The process is as follow:
1) Identify both the rule and the monitor in question. They first have to be disabled.
2) Change the rule sensitivity (I used 3.81 as a default)
3) Change the "Inner sensitivity" value on the monitor to be the same as the rule sensitivity value. Also take care that "Outer sensitivity" needs to be higher than that of the "Inner" value.
4) Enable both the rule and the monitor.
I will report back on the effectiveness of this tuning excercise; hoping this will work!
Links:
OpsMgr by Example
Rajeev Sudhakar
OpsMgr Alert: Number of RPC requests is outside the calculated baseline
Monitor Rule: Microsoft.Exchange.ExchangeComponent.IS.RPCRequests
The Number of RPC requests is outside the calculated baseline. The current value is 0.333333333333333
One could of course just ignore it (sure...) or completely disable the rule. I've been looking at two helpful posts (see links below) that seems to provide the answer, painstaking as the process is. The process is as follow:
1) Identify both the rule and the monitor in question. They first have to be disabled.
2) Change the rule sensitivity (I used 3.81 as a default)
3) Change the "Inner sensitivity" value on the monitor to be the same as the rule sensitivity value. Also take care that "Outer sensitivity" needs to be higher than that of the "Inner" value.
4) Enable both the rule and the monitor.
I will report back on the effectiveness of this tuning excercise; hoping this will work!
Links:
OpsMgr by Example
Rajeev Sudhakar
Tuesday, October 30, 2007
SMS 2003 SP3 Hotfix (941214) Blues
Yip, so after you deploy the "updated" client.msi (KB941214) you will see multiple 10021 events as you check the advertisement status for this package:
"The program was able to be executed but the system was restarted unexpectedly before the program could be completed or before status could be recorded. No installation status MIF was found after the system restarted"
Don't be alarmed, as per KB 840864 this is expected behaviour when a hotfix contains multiple other hotfixes, and the MIF files don't play nicely.
Gotta love the workaround suggested though! So glad I did not raise MOM alerts for this. Sigh...
"The program was able to be executed but the system was restarted unexpectedly before the program could be completed or before status could be recorded. No installation status MIF was found after the system restarted"
Don't be alarmed, as per KB 840864 this is expected behaviour when a hotfix contains multiple other hotfixes, and the MIF files don't play nicely.
Gotta love the workaround suggested though! So glad I did not raise MOM alerts for this. Sigh...
Subscribe to:
Posts (Atom)